 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Allan wrote:
> I have never heard
> anyone in my years of experience ever say the gcc compiler was "poor".
Then you clearly have insufficient experience. Try Google if you seriously
want specifics on the many gcc performance problems. The gcc mailing lists
are a good resource, too.
> to the "rushed and incomplete port" of OS X to the intel architecture:
> where have you been hiding the last few years? OS X has been running on
> intel processors since version 10.0.
This claim is complete nonsense: Mac OS X has not been available on x86
processors until last year (in beta versions on a single system
configuration). I suppose you are confusing Mac OS X with the Mach kernel,
which indeed has been running on x86 processors for decades now.
> Apple took their time to release the intel version for obvious marketing
> reasons.
To understand the difference between a rushed introduction and a planned
introduction, compare the current mess with the 68K to PowerPC transition:
At least by the time the first PowerPC systems shipped there was a working
and fully supported debugger available that would work on emulated and
native code. Further, native and emulated code could even be linked together
transparently by design. Neither is the case for the PowerPC to x86
transition. In fact, Apple quickly abandoned all attempts of even providing
a debugger for emulated code (and quite obviously to date there is none),
and to further rush the "transition", Apple also elected to provide
absolutely no way for native and emulated code to work together by any
means, let alone linking.
Of course, maybe a timeline is easier to understand for you: There were over
three years between the announcement of the transition to the initial
switch, while this time around everything from the announcement to
abandoning all previous hardware took just barely one year. Compare that to
similar transitions at HP/Compaq/DEC, Sun, SGI, or IBM. They all
concurrently develop their systems on different architectures for many
years, and most certainly none of them over dropped one processor
architecture for another literary from one day to the next, by public
announcement to developers and users at the same time. Not even SGI, which
certainly had every financial motivation to do so!
> As for the "broken emulator", Apple clearly states that well written and
> well behaved applications will run with no problem under Rosetta.
I have yet to read such a statement: I suppose you simply misinterpreted
some statement by Apple, but effectively it does not matter as fact is
Rosetta does not work with POV-Ray, yet POV-Ray runs on every real
PowerPC-based Mac, so how you can argue anything but that Rosetta is broken
is beyond logic :-(
Fact is that POV-Ray is an industry-standard benchmark application. If
Rosetta cannot handle it, it actually is either sign of incompetence on part
of the Rosetta developers or managers deciding to ignore Rosetta's problems.
My personal suspicion is that it is a management problem (aka Apple-"god"
Jobs), which also explains the rushed transition in general.
> I also have Silo v1.42 running with no problems. These are hardly trivial
> applications. What kind of platform dependent tricks do you employ in
> POV-ray that b) breaks Rosetta?
I have no idea what "tricks" you think there exist for such purpose. Either
you know very little about programming, or you are asserting POV-Ray 3.6 -
released years before Rosetta was even developed - was intentionally
designed to not work with Rosetta. As such, I can only conclude you either
don't know what you are talking about or you need serious help from a
psychiatrist...
> a) makes it difficult to port
I have already answered this question in a reply to you on September 25th.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> wrote:
>Then you clearly have insufficient experience. Try Google if you seriously
>want specifics on the many gcc performance problems. The gcc mailing lists
>are a good resource, too.
Could you please be a just a little bit more condescending? I am not sure
if you are really trying to piss me off or are just flaunting your vast
knowledge of everything and anything. While I do not claim to have a PHd
in anything, I do know a thing or two about computers having been
programming on the beasts since 1972. Plus, I have a number of
acquaintances, one who is a systems engineer at Craig and the other
formally of Pixar, who are fairly knowledgeable about gcc and they both
laughed when I told them what you said about gcc. Basicaly, unless you are
simulating atomic bomb blasts or running climate models, gcc is plenty fine
enough for ray tracing. (Take a look at MegaPOV on an intel Mac: it beats
the pants off of the G5 running PPC POV-ray any day.)
>> to the "rushed and incomplete port" of OS X to the intel architecture:
>> where have you been hiding the last few years? OS X has been running on
>> intel processors since version 10.0.
>This claim is complete nonsense: Mac OS X has not been available on x86
>processors until last year (in beta versions on a single system
>configuration). I suppose you are confusing Mac OS X with the Mach kernel,
>which indeed has been running on x86 processors for decades now.
Fact: Apple has been running OS X on intel processors since the inception of
OS X. Just look at the frigin 10.0, 10.1, 10.2, 10.3, etc, source code! Do
you think they were coding #ifdef i386 for practice? Yes, indeed, they did
release OS X for intel just last year but it was hardly "rushed and
incomplete", it was just the right time to release it. The G5 was the top
of the line for PPC and they were not going to milk any more speed or
dollars out of it. Along comes intel dual core and now they have something
faster and better than the G5.
>To understand the difference between a rushed introduction and a planned
>introduction, compare the current mess with the 68K to PowerPC transition:
Considering the GUI interface on POV-ray for the Mac, what you need to
understand is this: forget Code Warrior, Code Warrior is dead, dead, dead.
Long live XCode. Code Warrior can RIP for all we Mac programmers care.
Take a few hours to learn Objective-C and Interface Builder and put a
decent front-end on the POV-ray C code and build a universal app for PPC
and intel.
I have said enough on this thread and will not be posting to it any more.
-Allan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 24 Oct 2006 22:50:59 EDT, "Allan" <all### [at] WholeCheesecom> wrote:
> Could you please be a just a little bit more condescending?
http://www.google.pl/search?q=poor+gcc+performance+mac gives
http://www.ctoforaday.com/articles/000019.html which repeats general notes
about gcc internal design problems I saw here and there.
HTH,
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Allan wrote:
>> This claim is complete nonsense: Mac OS X has not been available on x86
>> processors until last year (in beta versions on a single system
>> configuration). I suppose you are confusing Mac OS X with the Mach kernel,
>> which indeed has been running on x86 processors for decades now.
>
> Fact: Apple has been running OS X on intel processors since the inception of
> OS X. Just look at the frigin 10.0, 10.1, 10.2, 10.3, etc, source code! Do
> you think they were coding #ifdef i386 for practice?
Apple has only released the source code of the kernel, and thus your
statement is definitive proof that you do not understand what you are
talking about!!! The GUI and anything above kernel level (except standard
Unix OSS tools of course) were never released as source code, and have not
been to this day, all for very obvious reasons (they are confidential Apple
intellectual property).
Binary-only releases of those x86 system layers above the kernel level were
made available last year as part of the x86 versions of Mac OS X. And that
Mac OS X is more than its kernel and Unix environment should be clear to
even the most ignorant and clueless around. Of course, assuming you actually
know what a kernel is, which I suppose you don't know either :-(
> Considering the GUI interface on POV-ray for the Mac, what you need to
> understand is this: forget Code Warrior, Code Warrior is dead, dead, dead.
> Long live XCode. Code Warrior can RIP for all we Mac programmers care.
> Take a few hours to learn Objective-C and Interface Builder and put a
> decent front-end on the POV-ray C code and build a universal app for PPC
> and intel.
Which again shows you absolutely do not understand what you are talking
about. XCode, which is just an unreliable IDE for gcc, supports Apple Carbon
API (aka standard C and C++) development just fine, much better than Cocoa
API (aka Objective-C) in fact. Objective-C is a proprietary Apple-only
extension to gcc, and hence does not enjoy the widespread support as the
standard C and C++ compilers within gcc. That CodeWarrior has been
discontinued for Macs has absolutely nothing to do with porting.
In fact, you conveniently overlooked or did not understand that part in my
Sept 25 reply to you, where I explicitly point out the porting problems. If
you had understood what I was talking about, you would instantly have
noticed that neither of the issues listed there have anything to do with the
GUI frontend for POV-Ray. Porting that is almost trivial.
> I have said enough on this thread and will not be posting to it any more.
Thank you! You really have wasted my time long enough :-(
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oops, in my previous note I wrote "Craig". I meant to write "Cray". My
friend works at Cray, Inc., and has rather nice things to say about gcc but
I guess he is just another ignorant doofus like me.
BTW, Objective-C is not proprietary to Apple. There are many
implementations of Obj-C, even one on Windows. Cocoa, on the other hand is
Apple's but it is an API of classes for Apple's GUI, much like MFC is for
Windows. Interfacing a GUI front-end written in Objective-C with legacy
code written in C is trivial, but only a real Mac programmer would know
that.
Good Bye.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Allan wrote:
> Oops, in my previous note I wrote "Craig". I meant to write "Cray". My
> friend works at Cray, Inc., and has rather nice things to say about gcc but
> I guess he is just another ignorant doofus like me.
>
> BTW, Objective-C is not proprietary to Apple. There are many
> implementations of Obj-C, even one on Windows. Cocoa, on the other hand is
> Apple's but it is an API of classes for Apple's GUI, much like MFC is for
> Windows. Interfacing a GUI front-end written in Objective-C with legacy
> code written in C is trivial
<irony>What an amazing news! -- Code written in different programming
languages can be interfaced, really, amazing news!!! </irony>
For those still lost: Of course, it would be even more amazing if it hadn't
been old news many decades ago. Back in times when parts were written in
assembler, and others in higher-level languages. Naturally, there always
were way to interface the two, otherwise no program could run on an
operating system not written in the same language...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
