News for hackers. Stuff that matters.

lsr0

These results aren't reproducible when both are compiled with -O3 (similar results with -O2):

  ojc_parse_str    1000000 entries in  709.300 msecs. ( 1409 iterations/msec)
  simdjson_parse   1000000 entries in  450.724 msecs. ( 2218 iterations/msec)
In those results simdjson is roughly 60% faster.

Telling simdjson we have aligned input gives us further improvement:

  simdjson_parse   1000000 entries in  369.234 msecs. ( 2708 iterations/msec)
About 90% faster. Example changes:

   simd_parse(const char *str, int64_t iter) {
       simdjson::dom::parser parser;
       int64_t   dt;
  +    auto   padded = simdjson::padded_string(std::string_view(str));
       int64_t   start = clock_micro();
   
       for (int i = iter; 0 < i; i--) {
  -        simdjson::dom::element doc = parser.parse(str, strlen(str));
  +        simdjson::dom::element doc = parser.parse(padded);
       }
       dt = clock_micro() - start;
Re:New Concurrent Hash Maps for C++ on Tuesday February 02, 2016 @01:54AM (#11017975)
That seems to be the case, I do wish they'd made this requirement clear up front. There is no getting around sychronised quiescence being a blocking event, but in this case they essentially hope that either 1) you're already using a kind of scatter gather thread model like the mentioned game example - which implies an iterative discrete world, or 2) the set of threads (or tasks) interacting with the collection is simply bounded and sychronised, and/or 3) the performance is still better in aggregate even with infrequent world blocking events.
I used to work in the same industry. We used linux and gcc, so we could, and did, produce fully deterministic builds. Actually the output was fully deterministic disk images.

I did one iteration of the build system, mostly making it such that any host could build it deterministically. This was years ago so it was just chroot that started with a skeleton + GCC and procedurally built the things it needed to build the outputs. Was fairly straight forward, just an extremely short patch here and there, a 1000 line Xorg Makefile for staging Xorg builds. If I was doing it again I'd consider reusing a package manager, but each components Makefile was pretty concise. My trusty sidekick was a script that xxd'd two files into pipes that it opened using vimdiff.

Build took an hour or so, however.

Re:Skype TX on Monday April 07, 2014 @04:41PM (#7549324)
Working on it. Thanks for your feedback.

(Disclaimer: Skype Engineer)

Re:Skype 4.0 for Linux on Saturday June 16, 2012 @08:55AM (#4120545)
skype --dbpath=~/.otherskype