3 ms·
I find it hard to use the term "stagnate" to describe an industry that is developing its own specialized languages/systems (see Q/KDB) and is currently in the p
by bd_at_rivenhill 15y ago
I find it hard to use the term "stagnate" to describe an industry that is developing its own specialized languages/systems (see Q/KDB) and is currently in the process of exploring FPGA technology to improve performance. The secretive nature of the industry means that people outside it don't know what's happening on the inside, not that participants lack awareness of developments in more open industries.
Just to answer your point about CLR/JVM code performance: one early comment in the original article that stood out for me was "Pure computational performance (ignoring memory allocation/deallocation) under .NET runtime (ignoring vectorization) is pretty close to the performance of raw C++", which is all well and good except for the fact that you are going to end up with worse code than someone who doesn't ignore memory allocation and vectorization.
- KirinDave 15y ago> I find it hard to use the term "stagnate" to describe an industry that is developing its own specialized languages/systems (see Q/KDB) and is currently in the process of exploring FPGA technology to improve performance. That's fine. We disagree on what's the right direction for software engineering. I welcome debate on the subject. I don't consider migrating to customized hardware a cutting edge technique. It seems like every second justification I hear for the toolchains I see seems to revolve around performance complaints that are only reasonable in a hard-realtime situations or 2001. > which is all well and good except for the fact that you are going to end up with worse code than someone who doesn't ignore memory allocation and vectorization. Actually, that's exactly not what happens. Modern GC is good, man, really good. The vectorization scene is even better for the FP world.