3 ms·
>C is not well matched to CPUs + >depending on compiler optimizations + >Snabb uses LuaJIT .. quite tight code == You can write great C-based systems and avoi
by fit2rule 6y ago
>C is not well matched to CPUs
+
>depending on compiler optimizations
+
>Snabb uses LuaJIT .. quite tight code
==
You can write great C-based systems and avoid assembly if you a) know, always, what your compiler is doing and b) know, always, what your CPU is doing...
- exikyut 6y agoI'd be interested to learn about significantly complex, nontrivial systems of say 100K to 1M LOC scale that require reasoning about every single instruction from the perspective of every other instruction, in order for the system to work.
- benou 6y agoYou do not do that. Instead you optimize the short, critical part. Of course it does not apply to everything, you need a few hotspots, but it is quite common: audio/video codecs, scientific computation, games, crypto... And even networking.
- fit2rule 6y agoAnd with Lua (and C, and C++) its pretty easy to manage the complexity. Just put things where they belong.
- p_l 6y agoMy point was that the same optimizations that made C fast break down when you need to take into account often intricate dance between CPU caches, memory, I/O bus etc. - so that unless you go into cpu-model-specific assembly tweaks just using C might not bring you as much benefit. Is it possible to get better? yes. Would it count as "normal C"? I would say not really (if we say yes, then CL code on SBCL with huge custom VOPs counts)