Re: [Boost-users] [serialization] Runtime overhead of serialization archives

Subject: Re: [Boost-users] [serialization] Runtime overhead of serialization archives
From: Ernest Zaslavsky (ernest.zaslavsky_at_[hidden])
Date: 2016-09-25 01:05:17

I guess you are still comparing release to debug version. I've ran your code and this is what I've got

Win7 x64, VS2015 Update3, Release, x64

Run on (8 X 3392 MHz CPU s)
09/25/16 07:36:53
Benchmark                      Time           CPU Iterations
------------------------------------------------------------
to_wire_xml/8              39564 ns      39980 ns      17949   195.409kB/s
to_wire_xml/64             98915 ns      98035 ns       7479   637.527kB/s
to_wire_xml/512           583376 ns     583961 ns       1122   856.222kB/s
to_wire_xml/4k           4494721 ns    4428415 ns        155   903.258kB/s
to_wire_xml/32k         35621888 ns   35100225 ns         20   911.675kB/s
to_wire_xml/256k       285296564 ns  280801800 ns          2   911.675kB/s
to_wire_xml/2M        2294702350 ns 2293214700 ns          1   893.069kB/s
to_wire_xml/4M        4596100456 ns 4586429400 ns          1   893.069kB/s
from_wire_xml/8            44701 ns      44361 ns      15473    176.11kB/s
from_wire_xml/64           97779 ns      98035 ns       7479   637.527kB/s
from_wire_xml/512         523956 ns     530403 ns       1000   942.679kB/s
from_wire_xml/4k         3919513 ns    3877482 ns        173    1031.6kB/s
from_wire_xml/32k       30990532 ns   31200200 ns         22   1025.63kB/s
from_wire_xml/256k     248254367 ns  249601600 ns          3   1025.63kB/s
from_wire_xml/2M      1990579271 ns 1981212700 ns          1   1033.71kB/s
from_wire_xml/8M      7927240207 ns 7924850800 ns          1   1033.71kB/s
to_wire_text/8             13381 ns      13142 ns      49857   594.483kB/s
to_wire_text/64            31969 ns      31985 ns      22436   1.90827MB/s
to_wire_text/512          180335 ns     179751 ns       4079   2.71643MB/s
to_wire_text/4k          1363654 ns    1375560 ns        499   2.83975MB/s
to_wire_text/32k        10990438 ns   10968820 ns         64   2.84898MB/s
to_wire_text/256k       86883137 ns   88400567 ns          9   2.82804MB/s
to_wire_text/2M        696132001 ns  686404400 ns          1   2.91373MB/s
to_wire_text/4M       1398212634 ns 1388408900 ns          1     2.881MB/s
from_wire_text/8           11158 ns      11195 ns      64102   697.873kB/s
from_wire_text/64          25274 ns      25588 ns      28045   2.38534MB/s
from_wire_text/512        138245 ns     137666 ns       4986   3.54685MB/s
from_wire_text/4k        1047166 ns    1046497 ns        641   3.73269MB/s
from_wire_text/32k       8304279 ns    8320053 ns         90   3.75599MB/s
from_wire_text/256k     66510527 ns   66654973 ns         11   3.75066MB/s
from_wire_text/2M      533393808 ns  530403400 ns          1   3.77071MB/s
from_wire_text/4M     1055956857 ns 1060806800 ns          1   3.77071MB/s
to_wire_binary/8            5444 ns       5460 ns     100000   1.39732MB/s
to_wire_binary/64           5411 ns       5424 ns     112179   11.2538MB/s
to_wire_binary/512          5523 ns       5563 ns     112179   87.7797MB/s
to_wire_binary/4k           5966 ns       5980 ns     112179   653.244MB/s
to_wire_binary/32k         28940 ns      29412 ns      24929    1062.5MB/s
to_wire_binary/256k       251626 ns     250358 ns       2804   998.569MB/s
to_wire_binary/2M        2548630 ns    2540925 ns        264   787.115MB/s
to_wire_binary/4M        6361041 ns    6407184 ns        112   624.299MB/s
from_wire_binary/8          5363 ns       5284 ns     112179   1.44375MB/s
from_wire_binary/64         5371 ns       5460 ns     100000   11.1785MB/s
from_wire_binary/512        5386 ns       5460 ns     100000   89.4282MB/s
from_wire_binary/4k         5483 ns       5424 ns     112179   720.244MB/s
from_wire_binary/32k        7685 ns       7649 ns      89743   3.98998GB/s
from_wire_binary/256k      25332 ns      25588 ns      28045   9.54136GB/s
from_wire_binary/2M       620654 ns     625672 ns       1122   3.12164GB/s
from_wire_binary/4M      1306333 ns    1306960 ns        561   2.98881GB/s

-----Original Message-----
From: Boost-users [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Georg Gast
Sent: Sunday, September 25, 2016 6:42 AM
To: boost-users_at_[hidden]
Subject: Re: [Boost-users] [serialization] Runtime overhead of serialization archives

Am 22.09.2016 um 22:38 schrieb Chris Glover:

> For what it's worth, in tests I've done in the past, binary 
> serialization using boost.serialization and other similar systems was 
> not this big of a difference compared to memcpy. I was seeing maybe a 
> 5x to 10x difference compared to memcpy (yours is 50x).
> 
> Of course, this depends on a lot of factors, like how much data this 
> is because it would determine if you are memory bound or not, but I am 
> wondering if your cstyle tests are actually being completely optimized 
> away. Have you examined the disassembly? If you find the code is being 
> optimized away, Google Benchmark has a handy "benchmark::DoNotOptimize"
> function to help keep the optimizer from throwing away the side 
> effects of a particular address.

Hi,
i have prepared a comparison of the same code between linux and windows (msvc). There is such a huge gap between linux and windows.

I am not sure, if i should post the images to this mailing list. AFAIK is it seen as bad behaviour to post non text to this list, so i added the link.

https://www.schorsch-tech.de/doku.php?id=c:boost_serialization&#windows

Has anyone an idea why this is the case? Look at this diagrams, i cant explain whats happening here. its on the same maschine on bare metal (no VM).

  Georg
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users