| IDLSpecII and beyond [message #19474] |
Wed, 22 March 2000 00:00 |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
Due to a script issue which occurred during an OS upgrade mandated by IDL v5.3,
the IDLSpecII survey data was not updated for about a month. Apologies to those
who entered but didn't see their standings. The problem has been fixed and you
can view your results at:
http://www.astro.cornell.edu/idlspec/
Limitations in the range of some tests on fastest machines (in which individual
tests take virtually 0 time) have motivated some thought on improvements to the
time tests, perhaps forking away from the increasingly less adequate
RSI-supplied time_test and graphics_times suite. Rather than arbitrarily
starting test-coding based on my IDL experience and usage, I wanted to solicit
general comments about the type of things people would like to see tested. So
far, my rough list of changes/additions is:
1. Increase the sizes of arrays used in tests. Assume minimum working memory
sizes of ~32MB to design array-based tests, avoiding VM access, but actually
stressing off-chip/card memory subsystems.
2. Bring in more relevant routines.. the real work horses that people are
using, and whose speed they really care about. You can use:
IDL> profiler, /RESET, /SYSTEM
IDL> my_slow_routine_which_runs_overnight
IDL> profiler, /REPORT
and look for the most heavily used and slowest system (S) routines. Up to know,
we've been testing: basic array math, shift(), randomu(), ludc(), transpose(),
alog(), fft(), and smooth().
3. Design robust I/O tests which don't just test OS caching policies, but
really probe the underlying hardware. I/O is difficult to isolate from memory,
but a good first step would be increasing the size of the data set written,
and/or to implement sync'ing in some way to ensure the data has actually been
written physically to disk before the test returns. Suggestions?
4. Object Graphics. This could open a whole can of worms with regards to
OpenGL hardware vs. software support etc., but as people increasingly rely on
OG, the tests should take this into account. As I work little with OG, I'd need
lots of community feedback on the types of things which would be well-suited to
testing.
I would appreciate any comments people have about the ingredients of an updated
IDL speed test suite which are indispensable.
Thanks,
JD
--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-6263
304 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
