Re: IDLSpecIII -- Volunteer Needed

[Martin Schultz <martin.schultz(at)dkrz.de>]

John-David Smith <jdsmith@astro.cornell.edu> writes:


I'd advocate a WHERE (and general indexing) test. This is one of the 
functions I use most and on pretty large arrays, too.

Example:
PRO wtest

    a = findgen(500, 500, 20)
    a = transpose(a,[1,2,0])
    ; get start time
    t0 = systime(1)
    i = where(a gt 5000. AND a lt 10000.)
    t1 = systime(1)
    ; get stop time

    print,t1-t0

 END

On my PentiumIII Dual 500MHz this takes about 0.6s


Cheers,
Martin

> I posted this deep in another thread, but thought I might just put it out for
> all too see.  Sorry for the wasted bits.  
> 
> 
> 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. Others?
> 
> 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

-- 
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
[[ Dr. Martin Schultz   Max-Planck-Institut fuer Meteorologie    [[
[[                      Bundesstr. 55, 20146 Hamburg             [[
[[                      phone: +49 40 41173-308                  [[
[[                      fax:   +49 40 41173-298                  [[
[[ martin.schultz@dkrz.de                                        [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[