| Re: IDL 5.4 and MacOS 9.1 -- updating IDLSpec [message #25326] |
Thu, 07 June 2001 09:31 |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
Dominik Paul wrote:
> So, another thing we observed is, that a big calculation a P3 with 900Mhz
> and 512MB took 42 secs, while on a Mac the same calculating only took 22
> secs. Does somebody have experience in performance comparison Mac<->PC ???
You can look at the (old) performance spec for IDL at:
www.astro.cornell.edu/idlspec
It's a bit out of date by now, not even officially supporting v5.4
(though I guess the 5.3 compile works for it too, as it has a few 5.4
entries now).
The Macs are in green, and not painted in a pretty picture. They fare
well in processor tests (for the processor speed), but are very
lackluster in I/O performance.
However, there is a *huge* caveat: the I/O tests represented by RSI's
time_test suite typically do not tax the physical drive+bus speed, but
are instead quite sensitive to the OS's I/O caching policy. Traditional
MacOS has a classically sub-optimal caching policy, but this should be
relieved with OS X.
The red and orange are x86 machines (Windows and Linux, respectively).
As an example of OS caching issues, notice that the orange symbols
follow a more nearly straight line than the red, indicating that Linux
I/O caching scales more evenly with processor speed, for the same
hardware.
VOLUNTEERS NEEDED:
I'd like to solicit volunteers to help construct IDLSpecIII, which will
likely be based from IDLv5.5, including the MasOSX version, and will
probably be hand rolled, rather than based on the problematic time_test
suite supplied by RSI. I am happy to take care of the management and
building the site. What I need most are performance nuts who want to
devise reasonably taxing tests of processor, I/O, and graphics speed.
I'm open to the idea of Object Graphics tests too, but I don't have much
experience there. Among the desiderata:
1. A suite of processor-intensive tests (must fit in memory -- we don't
want to test the Virtual Memory of the OS with this! -- is 32MB a
reasonable assumption for free real memory available to IDL?). Some of
the tests in !DIR/lib/time_test.pro are relevant: array addition, for
loop speed, matrix inversion, etc. I'd like to add more "real world"
processor-intensive code, based on common user operations. (Histogram,
anyone?)
2. A suite of several I/O performance tests. Currently only
read/writes of a 512x512 byte array (that's right, 256kB) occur. This
obviously fits in the disk cache of most hard drives, not to mention the
OS cache. 10-50MB is probably a more reasonable test size. Is 100MB
reasonable, in the context of multi-GB drives?
3. A suite of direct graphics tests. The standard graphics_times may
suffice here, with maybe a pixmap copy added.
4. (Possible) A suite a object graphics tests, with and without
hardware rendering enabled. This one will be all over the map, I
suspect. To run this test, users *must* specify a video card.
The chief guiding principle to keep in mind is separation of subsystem
taxed: mixing processor tests with I/O tests (as is hard to avoid on
modern VM/cached OS's) dilutes their discriminatory power.
Please let me know if you're interested.
Thanks,
JD
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
