[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDL i/o on G4



"Dmitri A. Sergatskov" wrote:
> 
> Looking at IDLSPEC2 numbers for Macs (G4 in particular), it appears that
> I/O performance is abysmal. Does anyone have an insight why would it
> be so bad? The STREAM benchmark suggests that it should not be a generic
> G4/MacOS problem.
> 

Not sure if I addressed this on the page... the current suite of IDL
tests as presented in time_testn library routines do not sufficiently
tax the I/O hardware subsystems.  The scatter you see in timings results
almost entirely from caching policies of the underlying OS (with the
on-board caching of modern harddrives a secondary complication).  That
is, some of these OS's are not actually physically comitting bytes to
disk, but caching them in memory (which is a perfectly acceptable
practice).

As it happens, MacOS has a pretty pitiful caching policy, which is
pretty well known.  I imagine if those numbers were replotted under
MacOSX, it would line up reasonably well with other OS's.  I also
imagine doing heavy duty I/O where your cache policy is irrelevant would
equalize things (though I'd suspect the MacOS I/O subsytem would still
suffer).

One other thing to remember: the speed advantages of G4's Altivec unit
are not built into the IDLSpec2 survey, since they were introduced in
version 5.4.  

I had promised an update to IDLSpec which addressed these and other
issues.  Perhaps this summer.  In the meantime, it seems the standard
time test suite RSI distributes doesn't do exactly what we want. 
Certainly the I/O testing can be improved and made more real-world
applicable.  Perhaps OpenGL performance can also be addressed.  

I'm always open to suggestions on this, but I can't promise anything new
in the near term.

JD