lsr0
Re:A Journey building a fast JSON parser and full JSONPath, Oj for Go
on Sunday July 05, 2020 @01:38PM (#23740380)
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.
Re:Deterministic, bit-identical and/or verifiable Linux builds
on Saturday July 12, 2014 @12:58PM (#8025051)
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.
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