5 ms·

It has about 15 KB of data: 10KB in power_of_ten_components and 5KB in mantissa_128. [1] That's ~23% of the per-core L1 data cache on (eg) the recently announce

It has about 15 KB of data: 10KB in power_of_ten_components and 5KB in mantissa_128. [1] That's ~23% of the per-core L1 data cache on (eg) the recently announced APU chip. [2, 3] So before getting too excited about the microbenchmark numbers, I'd be careful to ensure the additional cache pressure doesn't slow down my program as a whole. edit: also, ~2.5KB of that is due to padding in power_of_ten_components. I wonder if it'd be better to split the uint64_t field into two uint32_ts to avoid this. [1] https://github.com/lemire/fast_double_parser/blob/master/include/fast_double_parser.h https://github.com/lemire/fast_double_parser/blob/master/inc... [2] https://news.ycombinator.com/item?id=22440894 https://news.ycombinator.com/item?id=22440894 [3] https://en.wikichip.org/wiki/amd/ryzen_embedded/r1606g https://en.wikichip.org/wiki/amd/ryzen_embedded/r1606g

userbinator 7y ago
Also, I know it's not always possible, but if your application is spending so much time parsing strings into numbers that this could make a difference, seriously consider whether the source of those strings could be changed to not emit strings, because unless it's something like user input, chances are they may already be doubles which can be used as-is.
- thedance 7y ago
  HN is collectively schizophrenic on this topic. On the one hand, the comments say that nobody really needs anything fancier than JSON. On the other hand, other comments say that if JSON parsing shows up in your profiles, you should switch off JSON!
  - gameswithgo 7y ago
    that just reflects that actual engineers and not actual engineers frequent hn
  - userbinator 7y ago
    HN (and a lot of other places, really) has a large population of web or otherwise "web-heritage" developers, as well as those whose ventures into computing started beside/before the web. I suspect the JSON promotion comes mostly from the former group, while the latter, of which I am a member, laments it roughly as much as we did the "XML craze" of the late 90s and early 2000s.
    - cm2187 7y ago
      And a tiny minority I am proudly part of, who watches these debates about xml vs json or tabs vs whitespace with the same amusement than Mike Judge!
      - xxs 7y ago
        C'mon spaces vs tab is a serious one and it makes sense... unlike xml, json shizz.
        saagarjha 7y ago
        Spaces versus tabs is a stupid debate because "tabs for indentation, spaces for alignment" is clearly the correct answer.
    - xxs 7y ago
      Indeed, hand rolled fixed point network marshaling, preferably with delta encoding for time series alike data (or data that oscillates) is couple of orders of magnitude faster and but also significantly "smaller" than a double-string-double, counterpart. Getting ~1 byte per data point of time series is quite achievable.
      - vbezhenar 7y ago
        How do you encode floating point delta into one byte?
        thedance 7y ago
  - scottlamb 7y ago
    I think if you're a little more generous and say "you rarely need" rather than "nobody really needs", there's no contradiction. Most of the time, you're not using much CPU in total or your server is doing something much heavier than parsing and serialization. Either way, JSON is fine. Improving its performance is nice but not worth a ton of effort. Once in a while, it's significant, and you switch to a binary format if you can. And like anything, it depends on what you're doing. If you're doing lots of server-to-server RPCs on big distributed systems like within Google, it's much more reasonable to start with protobuf or the like than with JSON. And not just for performance reasons; having the generated code helps a lot with maintainability. (Some JSON libraries have something similar; some don't.)
    - zozbot234 7y ago
      Hexfloats are not a binary format, they're as text based as anything else. And they get rid of significant bottlenecks in float parsing.
      - thedance 7y ago
        But the existence of the hex float format, and the fact that it accepts either 0x or 0X, upper or lowercase characters for A-F, dot or comma for the point depending on locale, and either p or P for the exponent, all contribute to the reasons why strtod is so slow. The faster library in this article handles none of those things. It also does not handle NaN or INF.
  - XMPPwocky 7y ago
    Couldn't it just be different users posting those?
    - mandelbrotwurst 7y ago
      That's exactly what this person is saying / what they intended by the phrase "collectively schizophrenic".
      - XMPPwocky 7y ago
        Okay, but then "people disagree about this" seems a bit less interesting?
kzrdude 7y ago
A serious question is how can we make microbenchmarks that take this into account? Along the lines of measuring a speedup of an operation, in varying scenarios of cache pressure.
- vbezhenar 7y ago
  I'm not sure about actual implementation, but one approach would be to copy this function 100 times and invoke those copies sequentially. Of course linker must not optimize it into one function, so that's why I'm not sure about actual implementation. May be naive approach would work or may be not.

userbinator 7y ago

Also, I know it's not always possible, but if your application is spending so much time parsing strings into numbers that this could make a difference, seriously consider whether the source of those strings could be changed to not emit strings, because unless it's something like user input, chances are they may already be doubles which can be used as-is.

thedance 7y ago
HN is collectively schizophrenic on this topic. On the one hand, the comments say that nobody really needs anything fancier than JSON. On the other hand, other comments say that if JSON parsing shows up in your profiles, you should switch off JSON!
- gameswithgo 7y ago
  that just reflects that actual engineers and not actual engineers frequent hn
- userbinator 7y ago
  HN (and a lot of other places, really) has a large population of web or otherwise "web-heritage" developers, as well as those whose ventures into computing started beside/before the web. I suspect the JSON promotion comes mostly from the former group, while the latter, of which I am a member, laments it roughly as much as we did the "XML craze" of the late 90s and early 2000s.
  - cm2187 7y ago
    And a tiny minority I am proudly part of, who watches these debates about xml vs json or tabs vs whitespace with the same amusement than Mike Judge!
    - xxs 7y ago
      C'mon spaces vs tab is a serious one and it makes sense... unlike xml, json shizz.
      - saagarjha 7y ago
        Spaces versus tabs is a stupid debate because "tabs for indentation, spaces for alignment" is clearly the correct answer.
  - xxs 7y ago
    Indeed, hand rolled fixed point network marshaling, preferably with delta encoding for time series alike data (or data that oscillates) is couple of orders of magnitude faster and but also significantly "smaller" than a double-string-double, counterpart. Getting ~1 byte per data point of time series is quite achievable.
    - vbezhenar 7y ago
      How do you encode floating point delta into one byte?
      - thedance 7y ago
- scottlamb 7y ago
  I think if you're a little more generous and say "you rarely need" rather than "nobody really needs", there's no contradiction. Most of the time, you're not using much CPU in total or your server is doing something much heavier than parsing and serialization. Either way, JSON is fine. Improving its performance is nice but not worth a ton of effort. Once in a while, it's significant, and you switch to a binary format if you can. And like anything, it depends on what you're doing. If you're doing lots of server-to-server RPCs on big distributed systems like within Google, it's much more reasonable to start with protobuf or the like than with JSON. And not just for performance reasons; having the generated code helps a lot with maintainability. (Some JSON libraries have something similar; some don't.)
  - zozbot234 7y ago
    Hexfloats are not a binary format, they're as text based as anything else. And they get rid of significant bottlenecks in float parsing.
    - thedance 7y ago
      But the existence of the hex float format, and the fact that it accepts either 0x or 0X, upper or lowercase characters for A-F, dot or comma for the point depending on locale, and either p or P for the exponent, all contribute to the reasons why strtod is so slow. The faster library in this article handles none of those things. It also does not handle NaN or INF.
- XMPPwocky 7y ago
  Couldn't it just be different users posting those?
  - mandelbrotwurst 7y ago
    That's exactly what this person is saying / what they intended by the phrase "collectively schizophrenic".
    - XMPPwocky 7y ago
      Okay, but then "people disagree about this" seems a bit less interesting?

kzrdude 7y ago

A serious question is how can we make microbenchmarks that take this into account? Along the lines of measuring a speedup of an operation, in varying scenarios of cache pressure.

vbezhenar 7y ago
I'm not sure about actual implementation, but one approach would be to copy this function 100 times and invoke those copies sequentially. Of course linker must not optimize it into one function, so that's why I'm not sure about actual implementation. May be naive approach would work or may be not.