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...
|
