141–150 of 376 posts
https://www.usenix.org/system/files/conference/hotos15/hotos...
Earlier quoted context omitted.
There is a significant amount of question submission, commenting and voting going on on SO.
A slim subset of humans typing things is not what I would label "write heavy". Write heavy is more like 100k+ devices out in the field sending their current position every 10s. That's still very manageable, but requires some thoughtful design.
Earlier quoted context omitted.
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
This is the quickest way to kill your performance in C++. I guarantee it wasn’t what Carmack was talking about. I used sharedptr extensively in a game engine. Whoops: suddenly 20% of the frame time was gone, never to be recovered. Once that performance is gone it’s almost impossible to get it back, short of rewriting every system.
Earlier quoted context omitted.
This sounds like an architecture problem, not a language problem. Can you elaborate?
Of course it's possible to write a horizontally scaled application in Java or C++. But once you have to deal with horizontal scaling anyway , language performance is much less of an advantage: as Carmack says, the difference between 100 servers and 10 is just accounting.
I've been programming C++ and assembly for 23 years. Few years ago I became a huge fan of Python. In my opinion Python is amazingly well suited for rapid first revision and can then be swapped out for C++ / asm.
This is fine as long as you can convince management to spend the money to rewrite your software. That's usually a hard sell though. In my experience this plan usually ends up with a python monstrosity that everyone hates but is forced to deal with forever.
Earlier quoted context omitted.
At the risk of exposing my ignorance - look at all those "Peak 5%-20%" labels. Doesn't that mean they have a lot more than they need?
Stack overflow hosts all (most?) Of their own baremetal servers in their own data center. Looking at the specs of the machines, they are actually pretty basic as far as servers go. A server isn't barely worth the cost of it's chassis and motherboard if you put less than 64 G ram and 24 CPUs in it. In other words, these are about the lowest specd proper servers you can get. So yeah, even their modest hardware is still…
Earlier quoted context omitted.
Out of curiosity, what is the field for which you find this to be true?
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
This is precisely the point made by McSherry, Isard and Murray in their lovely paper, "Scalability! But at what COST?" (Usenix HotOS '15). They demonstrate how much performance headroom there is in modern CPU and memory, and show how simple cache-sensitive batch algorithms running on a single core can outperform hundreds of cores running distributed map-reduce style jobs. https://www.usenix.org/system/files/conferenc…
vibe.d is well worth a look: https://vibed.org/
Isn't D dead practically? https://news.ycombinator.com/item?id=21902953
Earlier quoted context omitted.
One thing to keep in mind that their work-load is very ready-heavy which eases things a lot when scaling the system. The same is true for Wikipedia. Scaling a write-heavy workload is way more complex than scaling a read-heavy workload.
SO content changes all the time. Votes, comments, moderation, edits, tagging, search and recommendations, etc. There are also real-time community features. It's not as simple as it seems.
I guarantee you the bulk of traffic to SO is hitting a page and performing zero writes.