4 ms·
> HW embedded within the memory that could be given a small (safe) executable program to process the memory in-place rather than evaluating it on the CPU Well,
by BenoitP 6y ago
> HW embedded within the memory that could be given a small (safe) executable program to process the memory in-place rather than evaluating it on the CPU
Well, that seems to be the exact definition of what UPMEM is doing:
https://www.upmem.com/upmem-announces-silicon-based-processing-in-memory-benchmarks/ https://www.upmem.com/upmem-announces-silicon-based-processi...
Between the M1, GPUs, TPUs, RISC-V interesting times are coming in hardware. I blame the physical limits, which are putting the Duke Nukem development method to an end (you promise the client 2x the same performance in 18 months, then play Duke Nukem the whole time). The only way to better performance now is through hardware specialization. That and avoiding Electron.
- WJW 6y agoYou'd hope that the only way to better performance was HW specialisation, but there are SO MANY algorithmic improvements still to be made. Just the other day I found a case someone had rolled their own priority queue with a sorted array instead of a heap. In a fairly popular open source library too. There's still loads of performance to be gained just by being better programmers.
- Arelius 6y ago> Just the other day I found a case someone had rolled their own priority queue with a sorted array instead of a heap. I feel like this story needs an ending? Did somebody re-implement it using a heap and found significant performance wins? Or was the sorted array used on purpose to take advantage of some specific cache constraints and actually end up being a huge win?
- WJW 6y agoThe story ends (so far) with me filing a GH issue and offering a PR, my own benchmarking getting an average 3x speedup over a wide range of inputs. I happen to know that the maintainer has been on vacation for the last week and only got back a few days ago so no further discussion has been had yet.
- vlovich123 6y agoA serious HW perf improvement will, generally improve everything, including shitty algorithms. There’s a reason that through the 90s and 2000s serious developers routinely ignored spending significant time optimizing code because the hardware doubled the speed of ALL code every ~12-18 months. So even though there are low-hanging fruit for software optimization, such low-hanging fruit can be missing from already heavily optimized code (eg games, scientific computations etc) and is orders of magnitude more expensive than “run this on newer HW for faster perf”. If you can do this “transparently” (max some OS/compiler integration and you can use the new Hw for perf wins), then the cost economics are powerful. If it’s a special-purpose piece of HW then it gets trickier and will be relegated to accelerating certain memory-heavy programs (like GPUs accelerate certain kinds of mass-data algorithms).
- spockz 6y agoHow do you propose to fix this? Should languages include high(er?) performance data structures in their standard libraries? Or possibly even include some segmentation for small/medium/huge data sets?
- Tom4hawk 6y agoI'm not a person you asked but in my opinion answer is very simple: YES Example: https://www.youtube.com/watch?v=HgtRAbE1nBM&t=43m15s https://www.youtube.com/watch?v=HgtRAbE1nBM&t=43m15s
- xiphias2 6y agoBetter abstractions are the solution, not better programmers. Actually with better abstractions worse programmers are able to achieve the same thing.
- hinkley 6y agoMany of my problems at work are due to people in the uncanny valley between using libraries and writing their own.