stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Benchmarking stdcxx
Date Tue, 21 Feb 2006 01:00:35 GMT
Andrew Black wrote:
> Greetings all.
> 
> Part of the intent for subversion submits r379032 through r379035 (as I 
> understand them) was to address some of the slowness in the stringstream 
> operations that was detected by the previous benchmarking run.  With a 
> fresh benchmark run, the following are the results I get.  Results are 
> user times in seconds, found by taking the average of  3 runs of 500000 
> itterations.
> 
> +-------------------+-------+------------+---------+
> | stringstream_bm   | glibc | stdcxx_old | stdcxx  |
> +-------------------+-------+------------+---------+
> | read_write_multi  |  0.68 |       1.05 |    1.05 |
> | read_write_single |  7.99 |      14.43 |   14.41 |
> | write_multi       |  1.13 |      30.78 |    1.15 |
> | write_read_cycle  |  0.05 |       0.43 |    0.44 |
> | write_read_multi  |  7.58 |      46.53 | N/A     |
> | write_read_single |  8.08 |      45.76 |   15.37 |
> | write_single      |  2.00 |      31.02 |    2.36 |
> | read_multi        |  0.61 |       0.83 |    0.84 |
> | read_single       |  7.92 |      14.28 |   14.13 |
> | read_write_cycle  |  0.05 |       0.42 |    0.44 |
> +-------------------+-------+------------+---------+
> 
> The bigest improvments spotted are in the write_single, write_multi, and 
> write_read_single tests (with the first two approaching the speed of 
> glibc).  The write_read_multi test also showed a fair amount of 
> improvement (to 1.16 seconds),

Great! That's a significant improvement! I suspect the difference
we continue to see in some of these numbers might be due to the
allocation policy employed by our implementation which strives
for a balance between runtime speed and space efficiency. It would
be good to verify this hypothesis by changing our allocation policy
in the benchamrk to match the native one.

> but the benchmark segfaults, so I must 
> discard the results of this test as unreliable.
> 
> I suppose it would make sense to note this failure with the STDCXX-149 
> JIRA incident.

I reproduced the core dump but I don't think there's anything wrong
with the library. I removed the stringstream code from the the test
and the program still core dumps (under Sun dbx), so it looks like
there's something wrong with the pointer arithmetic. I would suggest
to simplify the benchmark code so as not to rely on tricky pointer
manipulation and dynamic memory allocation (use std::string instead).

Martin

Mime
View raw message