News for hackers. Stuff that matters.
Re:Distributed Systems Programming Has Stalled by hinkley on Thursday February 27, 2025 @01:03PM (#43196786)
I think SaaS and multicore hardware are evolving together because a queue of unrelated, partially ordered tasks running in parallel is a hell of a lot easier to think about than trying to leverage 6-128 cores to keep from ending up with a single user process that’s wasting 84-99% of available resources. Most people are not equipped to contend with Amdahl’s Law. Carving 5% out of the sequential part of a calculation is quickly becoming more time efficient than taking 50% out of the parallel parts, and we’ve spent 40 years beating the urge to reach for 1-4% improvements out of people. When people find out I got a 30% improvement by doing 8+6+4+4+3+2+1.5+1.5 they quickly find someplace else to be. The person who did the compressed pointer work on v8 to make it as fast as 64 bit pointers is the only other person in over a decade I’ve seen document working this way. If you’re reading this we should do lunch.

So because we discovered a lucrative, embarrassingly parallel problem domain that’s what basically the entire industry has been doing for 15 years, since multicore became unavoidable. We have web services and compilers being multi-core and not a lot in between. How many video games still run like three threads and each of those for completely distinct tasks?

Re:Distributed Systems Programming Has Stalled by linkregister on Friday February 28, 2025 @12:00PM (#43207818)
> 8+6+4+4+3+2+1.5+1.5

What is this referring to? It sounds like a fascinating problem.

Re:Distributed Systems Programming Has Stalled by EtCepeyd on Friday February 28, 2025 @02:55PM (#43209618)
>> When people find out I got a 30% improvement by doing 8+6+4+4+3+2+1.5+1.5

> What is this referring to?

30 = 8+6+4+4+3+2+1.5+1.5

Re:Distributed Systems Programming Has Stalled by gue5t on Friday February 28, 2025 @01:17PM (#43208672)
Personally I've been inspired by nnethercote's logs (https://nnethercote.github.io/) of incremental single-digit percentage performance improvements to rustc over the past several years. The serial portion of compilers is still quite significant and efforts to e.g. parallelize the entire rustc frontend are heroic slogs that have run into subtle semantic problems (deadlocks and races) that have made it very hard to land them. Not to disparage those working on that approach, but it is really difficult! Meanwhile, dozens of small speedups accumulate to really significant performance improvements over time.