comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: IDL i/o on G4
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: IDL i/o on G4 [message #24217 is a reply to message #24212] Wed, 14 March 2001 17:14 Go to previous messageGo to previous message
John-David T. Smith is currently offline  John-David T. Smith
Messages: 384
Registered: January 2000
Senior Member
"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
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Minor problem with command line editing on SGIs
Next Topic: Re: Minor problem with command line editing on SGIs

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Oct 12 12:16:39 PDT 2025

Total time taken to generate the page: 0.16080 seconds