Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A lot of complex “scalable” systems can be done with a simple, single C++ server

twitter.com

Post reply on HN
Print view View original

101–110 of 376 posts

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#101

Post by stevenwoo »

sumeno wrote: post #78
8fingerlouie wrote: post #28

As someone who has implemented a complex system in C++ in this decade, I’d say he’s not wrong, but you need to carefully weight the pros and cons. In our case latency and real time demands mattered a lot (NASDAQ feed parser), to the point of the (potential) slowdown of a garbage collector kicking in was enough to rule out Java and .NET. It runs entirely in memory and on 64+ cores. We implemented our own reference cou…

Memory management in modern C++ is considerably easier than it used to be. Bespoke memory managers aren't really needed, you can do almost anything you need to without ever using new or delete.

Out of curiosity, what is the field for which you find this to be true?

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#102

Post by manigandham »

fnord77 wrote: post #97
IndrekR wrote: post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

> That means we transfer 55 TB data / month this isn't a lot. Helps that site is mostly text data. I know of a relatively small cloud security system that transfers petabytes/month to/from a handful of customers. 4 ingest pods, 8 pipeline pods, 7 time-series db servers, 2 sql servers

The amount of data transferred is meaningless to compare. SO is a relatively complex site with dynamic content and real-time features.

Compared to other similar sites like Reddit or Quora which are far slower yet running on more hardware, it shows what proper efficient architecture and code can do.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#103

Post by manigandham »

riyadparvez wrote: post #77
IndrekR wrote: post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

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.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#104

Post by manigandham »

perl4ever wrote: post #80
IndrekR wrote: post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

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?

Yes but the overall hardware is a one-time purchase and cheap considering all the other costs of the business. They're well provisioned to keep latency down and handle any unexpected outages.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#105

Post by yawn »

hliyan wrote: post #96
riyadparvez wrote: post #77

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.

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.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#106

Post by decebalus1 »

IndrekR wrote: post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

> SO ranks #36 in Alexa right now

It would rank way higher if they would be more webscale. It needs more Kubernetes, GraphQL and Golang /s

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#107

Post by 29athrowaway »

IndrekR wrote: post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

Plus a content delivery network.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#108

Post by kal31dic »

zerr wrote: post #58
zem wrote: post #52

vibe.d is well worth a look: https://vibed.org/

Isn't D dead practically? https://news.ycombinator.com/item?id=21902953

And yet dicebot continues to work in D, including for me for a while.

I'm hiring 25 D programmers, so I suppose it very much depends on what you mean by practically!

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#109

Post by lmm »

ummonk wrote: post #41

Yes, I’m always shocked by just how much performance overhead most languages have compared to C and similar lower level languages. It is a price worth paying for better language ergonomics, but I do wonder whether Rust might be able to give us the best of both worlds here.

The idea that GCed languages in general have Python-like performance is a dangerous myth. Languages that are managed but not interpreted (e.g. Java, OCaml, Haskell, C#, Swift) have performance characteristics that are much closer to C than to Python.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#110

Post by kjksf »

avip wrote: post #79
ginko wrote: post #73

Earlier quoted context omitted.

That’s not exactly what I would call good speedup.

The point of the code is not to speedup the execution of summing a list of random number, but rather to speedup the acknowledgement of N random python developers that they have some misconceptions about the GIL. I think it does that pretty well but, well, that's just like my opinion.

The major reason people use threads is to speed up compute intensive tasks.

Ideally, pure computation like the one in your example should get a speed up linear to number of threads. 2 threads -> 2x faster. 3 threads -> 3x faster, up to a number of cores.

If that's not happening then you have excessive locking.

In Python excessive locking is caused by GIL - Global Interpreter Lock. As the name implies, there's a single, global lock and execution in a single threads effectively blocks all other threads because it holds GIL captive.

What this particular benchmarks is showing is that GIL is as bad as everyone says: instead of getting 16x speedup, you get speedups that are almost within margin of error for such a coarse measure.

Post reply on HN