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
|