2 ms·

Going further down the road of only doing what your requirements demand (not writing a general purpose parser), I really enjoyed this talk. https://media.handma

Going further down the road of only doing what your requirements demand (not writing a general purpose parser), I really enjoyed this talk. https://media.handmade-seattle.com/context-is-everything/ https://media.handmade-seattle.com/context-is-everything/

lifthrasiir 5y ago
Don't get me wrong, I mostly agree to what the talk wants to say, but the talk itself doesn't do a good job at giving convincing reasons. In fact I think the OP is a much better replacement for that talk. There are several factual inaccuracies in the talk. For example on-demand or in-situ parsing has been a thing especially for many high-performance C++ JSON parsers, and they are exactly designed for the constraints described in the talk (no needs for parse tree, in-place mutation or cross referencing). So everything before the specialized integer array parsing can be mostly automated without heavy hammers like SIMD---those parsers would likely use that, but I don't care. You still need to recognizes those constraints in the first place but you don't always need to write your own code for making use of them. He did mention that dependencies are or can be liabilities, yet failed to state that more codes and contexts are also liabilities. It is correct to recognize implicit contexts that may be useful for the optimization, but it doesn't mean that every context should be utilized. For example later examples assume x86(-64), which is increasingly becoming a bad decision in general thanks to ARM servers. It is a balancing act to choose which context to utilize and which to ignore (so that the code can remain more generic for later uses or easier to understand) and the talk is mostly silent about this aspect. He also fails to mention testing, which is the main reason I believe the OP is a better substitute for the talk. You can't exactly compare your shiny optimized code with an older version of it, because you have distilled implicit contexts into the new code so they can be functionally different. You need to somehow make those implicit contexts into explicit contracts, probably using some other codes that are not continuously run, documentations (which everyone seem to overlook!) or folk, eh, collective team knowledge. This is a hard problem by its own and again the talk is pretty much oblivious about that.
- dundarious 5y ago
  I think the talk is very carefully laid out as an incremental journey, and each stepping stone involves contextual decision-making. I don't think Andreas is saying "you must end up with the SSE2 implementation at the end", or even that approaches like the OP are illegitimate -- I'm commending the OP for thinking about the problem the right way! But using machine-specific intrinsics is just another dependency decision very similar to deciding to use a given library -- you may choose otherwise, for good reason. I would have loved the talk and probably still thought of it and posted it, even if it ended before the intrinsics (but I think he does an excellent job at that part too). But porting SSE2 to Neon is actually pretty easy -- if you use https://github.com/DLTcollab/sse2neon https://github.com/DLTcollab/sse2neon, IME it's very easy to do incrementally (or avoid or postpone indefinitely, depending on your needs).

lifthrasiir 5y ago

Don't get me wrong, I mostly agree to what the talk wants to say, but the talk itself doesn't do a good job at giving convincing reasons. In fact I think the OP is a much better replacement for that talk. There are several factual inaccuracies in the talk. For example on-demand or in-situ parsing has been a thing especially for many high-performance C++ JSON parsers, and they are exactly designed for the constraints described in the talk (no needs for parse tree, in-place mutation or cross referencing). So everything before the specialized integer array parsing can be mostly automated without heavy hammers like SIMD---those parsers would likely use that, but I don't care. You still need to recognizes those constraints in the first place but you don't always need to write your own code for making use of them. He did mention that dependencies are or can be liabilities, yet failed to state that more codes and contexts are also liabilities. It is correct to recognize implicit contexts that may be useful for the optimization, but it doesn't mean that every context should be utilized. For example later examples assume x86(-64), which is increasingly becoming a bad decision in general thanks to ARM servers. It is a balancing act to choose which context to utilize and which to ignore (so that the code can remain more generic for later uses or easier to understand) and the talk is mostly silent about this aspect. He also fails to mention testing, which is the main reason I believe the OP is a better substitute for the talk. You can't exactly compare your shiny optimized code with an older version of it, because you have distilled implicit contexts into the new code so they can be functionally different. You need to somehow make those implicit contexts into explicit contracts, probably using some other codes that are not continuously run, documentations (which everyone seem to overlook!) or folk, eh, collective team knowledge. This is a hard problem by its own and again the talk is pretty much oblivious about that.

dundarious 5y ago
I think the talk is very carefully laid out as an incremental journey, and each stepping stone involves contextual decision-making. I don't think Andreas is saying "you must end up with the SSE2 implementation at the end", or even that approaches like the OP are illegitimate -- I'm commending the OP for thinking about the problem the right way! But using machine-specific intrinsics is just another dependency decision very similar to deciding to use a given library -- you may choose otherwise, for good reason. I would have loved the talk and probably still thought of it and posted it, even if it ended before the intrinsics (but I think he does an excellent job at that part too). But porting SSE2 to Neon is actually pretty easy -- if you use https://github.com/DLTcollab/sse2neon https://github.com/DLTcollab/sse2neon, IME it's very easy to do incrementally (or avoid or postpone indefinitely, depending on your needs).