Hi all, Let me cc this to hpx-users, because it covers some recent results on benchmarking our serialization library. Vinay and Hartmut, please forgive me for being late in response, my mind has been exhausted at my day-to-day job.
I’ve compiled those benchmarks (https://github.com/stellar-group/cpp-serializers) using trunk-gcc (gcc-6.0), boost-1.60 and hpx with HEAD on 17 Feb. I also removed avro library, because new gcc rejected to compile it, and updated thrift. Result I got are quite interesting — running benchmark for 1 million iterations gave me the following results: [09:02:07]:[email protected]:/home/abikineev/cpp-serializers/build:0:$ ./test 1000000 performing 1000000 iterations thrift-binary: version = 0.9.3 thrift-binary: size = 17017 bytes thrift-binary: time = 28548 milliseconds thrift-compact: version = 0.9.3 thrift-compact: size = 11597 bytes thrift-compact: time = 33778 milliseconds protobuf: version = 2006000 protobuf: size = 12571 bytes protobuf: time = 24545 milliseconds boost: version = 106000 boost: size = 17470 bytes boost: time = 16060 milliseconds msgpack: version = 0.5.9 msgpack: size = 11902 bytes msgpack: time = 30098 milliseconds cereal: size = 17416 bytes cereal: time = 13382 milliseconds hpx: size = 17433 bytes hpx: time = 12140 milliseconds hpx zero copy: size = 9433 bytes hpx zero copy: time = 8122 milliseconds Then I noticed, that version of cereal lib was quite old (namely 1.0.0) and I updated it to the latest 1.1.2. And I got results as follows: [09:20:26]:[email protected]:/home/abikineev/cpp-serializers/build:0:$ ./test 1000000 performing 1000000 iterations thrift-binary: version = 0.9.3 thrift-binary: size = 17017 bytes thrift-binary: time = 28025 milliseconds thrift-compact: version = 0.9.3 thrift-compact: size = 11597 bytes thrift-compact: time = 33802 milliseconds protobuf: version = 2006000 protobuf: size = 12571 bytes protobuf: time = 23843 milliseconds boost: version = 106000 boost: size = 17470 bytes boost: time = 16188 milliseconds msgpack: version = 0.5.9 msgpack: size = 11902 bytes msgpack: time = 30051 milliseconds cereal: size = 17416 bytes cereal: time = 13083 milliseconds hpx: size = 17433 bytes hpx: time = 12371 milliseconds hpx zero copy: size = 9433 bytes hpx zero copy: time = 8138 milliseconds Summarizing, to be honest I didn’t expect that we slightly outperform cereal, because it is quite concentrated on serialization itself and doesn’t perform some runtime checks as we do such as filter and zero-copy buffer presence, endianess, etc… If you want to play with parameters, I can send you the binary and my envs, or my local changes for cpp-serializers and cmake command. Sincerely, Anton. > On Mar 1, 2016, at 11:51 PM, Hartmut Kaiser <[email protected]> wrote: > > Vinay, > >> Thank you so much Hartmut for the pointers. I'll go through the links. Any >> quick insights on why HPX is a little slower than cereal? The byte size >> (for objects) seems to be similar for both. But the HPX results are >> impressive nonetheless! > > Those numbers have been collected a while ago and I believe we have improved > on those already. I don't remember what the actual reason was, however. I'm > cc'ing Anton, he is the main author of our serialization library, he might > have some more insights. > > Regards Hartmut > --------------- > http://boost-spirit.com > http://stellar.cct.lsu.edu > > >> >> Regards, >> Vinay >> >> On Tue, Mar 1, 2016 at 12:17 PM, Hartmut Kaiser <[email protected]> >> wrote: >> Hey Vinay, >> >>> I have a quick question with your experience with regards to >> serialization >>> library. I'm involved in another project(for graph processing - still >>> initial stage, at least for me) that is currently trying to decide what >>> serialization library works best for distributed runtime system. The >>> criteria is it has to be C++11 enabled. They don't want to use Boost. >> The >>> alternative we see is Cereal Serialization Library. What I wanted to ask >>> was did you have an experience with this library? Also, what test >>> parameters should I look into that'd give me an idea about its >> usefulness >>> in general (besides the time overhead)? >> >> We gave up on Boost serialization as well (most out of performance >> reasons) and implemented our own. The main criteria I'd look for is >> genericity, extensibility and performance. One (possibly minor) thing I'd >> look out for is whether a library supports zero-copy operations (i.e. >> avoids copying data, if possible). >> >>> Also, is there any other comparable library you could point to? >> >> There is a small project comparing the performance of various libraries >> here: https://github.com/thekvs/cpp-serializers. We have added our own >> serialization library to the mix in our fork of this project here: >> https://github.com/STEllAR-GROUP/cpp-serializers. >> >>> Btw, I hope the last tropical storm was not too disruptive there. >> >> Yah, all went by gracefully and all we got was some rain. >> >> HTH >> Regards Hartmut >> --------------- >> http://boost-spirit.com >> http://stellar.cct.lsu.edu >> >> > > _______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
