>On Sonntag, Dezember 9, 2001, at 11:29  Uhr, John M McIntosh wrote:
>
>>I'll second that, I wrote some to test file primitives. In case the 
>>mac users are wondering I've been playing with long name support 
>>and large files using the features of HFS+. However the GCC 
>>compiler produces lousy code, it's 1/3 the performance of 
>>CodeWarrior code.
>
>Just a note that John and I have in the meantime determined that 
>this is not the case, the problems seem to be elsewhere.  Both the 
>Micro- and Macro-Benchmarks indicate that code quality is very 
>close, with some benchmarks indicating an advantage for gcc and some 
>for CW.
>
>Marcel
>

Nailed it............

Yes the notes and benchmarks are flying back and forth.

Yesterday Santa came early and I got CodeWarrior 7. A bit unstable 
but it produces the same *poorly* running code that GCC does, at 
least it's not a compiler issue. So some more investigate with gprof 
shows that the low resolution millisecond clock resolves to clock() 
which under mac classic and carbon PEF's resolve to TickCount(). 
TickCount is cheap because it's just a low memory location of 1/60 of 
a second incrementing.

But under Mach-O the clock call becomes a real unix call which of all 
the choices for clock is *very* expensive when call a zillion times 
per second.

So change the ioLowResMSClock to use TickCount. Which actually uses 
the nanosecond clock under Mach-o! This then produces a VM with 
similar performance to the CW Classic Carbon PEF one!!!!!!!!!!!

Yes...

Now to look at the Unix code for the timmer code and maybe I'll use that
-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================