On Fri, Jan 30, 2009 at 2:49 PM, Elad Lahav <ela...@uwaterloo.ca> wrote: >> Getting back to the original problem, I'm wondering if a more detailed >> explanation of what is trying to be measured and why might help. Is it >> crypto performance (in which case, the crypto apis might be useful to >> look at), or something else? > > The root of the issue was my attempt to compare integer performance on a > T1000 with other machines that I am working on. This was the result of > rather poor performance I got on the T1000 running a web server with dynamic > workload, compared with a fairly recent 4-core Xeon. The libgcrypt-based > benchmark was supposed to extract the maximum out of the T1000 (which indeed > it did, as all 32 strands reported close to 250 million instructions per > second). It then occurred to me that the user-space environment was 32 bits, > and I was wondering if 64 bit code would perhaps work better. > > Just for reference, here are the results of this benchmark on different > machines. The results are specified in times to encrypt a 1 GB file, with > the number of parallel threads set to the number of execution units for each > machine: > > A (2 x 3.06 GHz Xeon model 2 stepping 5 with HT enabled): 1m29s (4 threads) > B (4 x 2.80 GHz Xeon model 2 stepping 5): 1m07s (4 threads) > C (1 GHz UltraSPARC T1, 8 cores, 32 strands): 48s (32 threads) > D (2.83 GHz Xeon E5440 4 cores): 21s (4 threads) > > --Elad >
Ahh.. is there something specific that leads you to believe it's related to integer performance? Also, can you reveal which webserver and any relevant configuration? _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org