From: Arlindo da S. <da...@al...> - 2008-03-29 22:14:16
|
Stefan, I did grib2.gex/grads v2 comparison on a Linux i686 box. There it makes sense: GraDS v2 took 2:34 while grib2.gex took almost a minute longer. 1) time lats4d -2 -i gfs.t06z.ctl -format stats 141.031u 12.973s 2:34.54 99.6% 2) time lats4d -i gfs.t06z.gdf -format stats -func 'g2(@)' 179.742u 26.513s 3:24.08 101.0% Arlindo On Sat, Mar 29, 2008 at 4:45 PM, Arlindo da Silva <da...@al...> wrote: > Stefan, > I just did some timings on my MacBookPro G4 (1.67GHz, 1GB RAM) and I got > some surprising results, see below. The benchmark was to cycle through the > 180MB Grib-2 file you sent me. For reference, I converted it to Grib-1 so > that I could have a reference. As expected, reading grib-1 is the fastest: > it took less than 2.5 wallclock minutes for the job to finish. Using GrADS > v2 took much longer: 10 wallclock minutes. The surprising result is that > grib2.gex completed in less than 8.5 wallclock minutes! I was expecting it > to be slower since for each lat-lon grid it spawns a 'wgrib2' process > capturing its stdout in a pipe. So there is overhead costs in starting a > process, writing/reading to/from the pipe. My only explanation is that > wgrib2 does its decoding in single precision while GrADS v2 uses double. > > How does grib2.gex compares to GrADS v2 on your Linux box? I expect them > to be in the same ballpark. > > Arlindo > > PS: You need the attached Lats4d for GrADS v2. (You need to edit lats4d.shfor addiing the -2 option) > > 1) time lats4d.sh -i gfs.test.ctl -format stats: > > > 36.907u 8.671s 2:23.52 31.7% 0+0k 0+9io 0pf+0w > > > 2) time lats4d.sh -2 -i gfs.t06z.ctl -format stats > > > 264.064u 48.255s 10:02.05 51.8% 0+0k 0+8io 0pf+0w > > > 3) time lats4d.sh -i gfs.t06z.gdf -format stats -func 'g2(@)' > > > 284.911u 77.193s 8:18.42 72.6% 0+0k 0+12io 0pf+0w > > > -- > Arlindo da Silva > da...@al... > -- Arlindo da Silva da...@al... |