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

261–270 of 376 posts

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

#261

Post by georgeisgeorge »

buzzkillington wrote: post #216
jacobsenscott wrote: post #196

Earlier quoted context omitted.

You never choose to hire dumb programmers. The choice is between 15 good cpp programmers and 4 good python programmers.

You have not had to interview the python devs I've had to interview. Last round, for the second best candidate who we hired at 130% the salary we initially offered, after the best candidate was snatched under our nose for what we were told was twice the salary we were offering: >"Last question, I saw that you wrote a 100 line function here, is this because you ran out of time?" >>"No. I don't like to break up my func…

Did you interview John Carmack by chance? http://number-none.com/blow/john_carmack_on_inlined_code.htm...

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

#262

Post by hubert1234 »

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

600k open websocket connections means that 600k people opened stackoverflow sites but dont click on anything right? Because they still only have 550req/s. Interesting how much more power you need just to keep track of state.

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

#263

Post by tluyben2 »

asdfasgasdgasdg wrote: post #160
tlb wrote: post #155

Earlier quoted context omitted.

No doubt there are people who do it for cynical reasons. But at least some people do it sincerely thinking it’s the right choice. It’d be more interesting to talk about them, and how they came to make the wrong decision for what they thought were the right reasona.

I think it's a bit presumptuous to say that the decision is "wrong". That paper demonstrated that a single server can outperform a small server farm on a toy problem. Nobody, not even google, solves pagerank in production as a batch job. Real problems are often more complex.

For many workloads, companies have tech leads and CTOs absolutely overarchitecting their stack. If you can run your entire system off of 4 loadbalanced $200/mo servers, why am I seeing hadoop/kafka/kubernetes/etc running on $10k+/mo premoney, so paid with investor money? Sure there are a lot of cases where this is fine, but I would say (from real life) that there are far more cases where this was a pretty poor choice. Usually proven to be even poorer when the tech lead leaves and no-one seemingly having a clue how it all works together, despite the whole docker/kubernetes/ci stories peddled to management. That is usually when I get asked to take a look.

In my experience these problems are definitely not always toy problems while some of them can, easily, be ran on 1 server for the expected lifespan of the company because the company will never get that much users/clients/data even though immensely profitable.

Not everyone (almost no one) is a FAANG and I find it offensive to use the company money (which can be investor money) to realise the wet dreams of the cto while the case for that architecture and the cost of it, makes 0 sense to the business and bottomline.

Obviously in life, things are nuanced and differ case by case but nah, real world problems are, generally, not more complex. They are more complex in some (rare) cases, like the one you named. But most companies are not doing anything like that, but they do have their cto’s gearing up for that incredibly unlikely future.

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

#264

Post by FpUser »

buboard wrote: post #83

people will bike to work to "save the environment" but won't use C direct on metal to reduce the carbon footprint of their code. For a guy like Carmack, it may be quite frustrating working with the constraints of pytorch etc. He ll probably end up making his own pytorh frontend in C, which as a bonus people will use to deploy models.

Hypocrisy is not such a rare animal. There is however extra factor here: biking to work if possible is your personal choice. Using your favorite tools at work: often not as much

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

#265

Post by cthalupa »

otabdeveloper4 wrote: post #234
cthalupa wrote: post #217

Earlier quoted context omitted.

This is a false dichotomy. You don't have to choose between 1 C++ developer and 15+ package of Python developers. Personal productivity is generally going to be slower in C++ than it is in Python. In most situations you would gain more productivity out of a similarly skilled Python dev as you are a C++ dev, so you'd probably need to hire more C++ developers. Unless your argument is "C++ devs are smart and Python devs…

> Personal productivity is generally going to be slower in C++ than it is in Python. No, it entirely depends on the skill and experience level of the programmer. > In most situations you would gain more productivity out of a similarly skilled Python dev as you are a C++ dev No, a good programmer with equally good knowledge of both languages will code equally fast in both. > This is a false dichotomy. You don't have t…

>No, it entirely depends on the skill and experience level of the programmer.

We're comparing programming languages. You control for the other variables - otherwise the comparison is meaningless. My argument is equally skilled programmers will generally be more productive in Python than C++.

>No, a good programmer with equally good knowledge of both languages will code equally fast in both.

Care to explain how? Huge amounts of the features in these higher level languages are explicitly to increase productivity, and it's generally pretty well accepted they're successful. In this very comment section there's multiple sets of people talking about having to implement their own reference counting systems, and all sorts of other things. Implementing those systems takes up productivity.

If any one language was the best at everything, we would only have one language. There's trade offs made, and that's why there frequently is a right language (or set of languages) for one job vs. another.

>You failed to see the point. Large teams of clueless programmers doing things slowly and badly is a feature of the system, not a bug. KPI's for managers don't include lowering headcount and cost cutting as an incentive. (And trust me, you really wouldn't like it if they did.)

This simply hasn't been the case anywhere I've worked at for a meaningful amount of time. Empire building was plenty discouraged at all of the places I have been employed long term and there were KPIs for reducing headcount, or maintaining it while taking on additional responsibility, and accounting was always happy to step in if costs were increasing without solid justification. Reducing headcount doesn't even have to mean firing people or managing them out - it can be not backfilling spots, helping people find teams with open headcount and transferring, etc. It's never bothered me any - if we have too many people for the amount of work, I'm more likely to get bored.

>Yet that's effectively what you just did in your specious 'productivity' argument.

You started this whole tangential discussion by taking shots at Python developers for no apparent reason. I'm not calling anyone names, or anything even remotely similar - different languages are frequently differently suited. There's obviously places where C++ makes a lot of sense.

I don't really have a horse in this race - right this moment, I'd do basically any serious project in rust, and cargo-script has me even doing small scripts in rust as well. Maybe Erlang or Elixir if OTP makes a lot of sense for the project.

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

#266

Post by tluyben2 »

kortilla wrote: post #244
FpUser wrote: post #238

Earlier quoted context omitted.

Talked to many people lit you mentioned. Large percentage repeats these points: 1) We always wait for database, so performance of our code does not matter . This comes from places where ironically the whole database can fit into RAM. 10+ gbps connectivity - well it is almost commodity for business so the latency is not much of a bottleneck. Fast IO to store data - well imagine array of Optane drives. Not very cheap b…

> Sorry but experienced developer can implement those just as fast as in any scripting language and it will save a ton on maintenance. This is just a no true Scotsman argument. For 10 years I’ve watched python/ruby shops drastically outpace projects in C++/Java shops. What you’re failing to realize is how trivial most apps are and how fast fully functional back ends can be created with frameworks in those languages (…

> I’ve spent entire days peeling apart complex C++ code bases to make a small change to some core abstraction.

I find that more an issue with people who think they need to abstract everything as far as they can as some kind of intellectual masturbation. You tend to have the same in some Java and C# codebases, where you keep digging through (slightly and subtly misused) design patterns to find what is going on. I can readily read and write codebases like Redis because it did not overdo abstraction.

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

#267

Post by FpUser »

cthalupa wrote: post #225
bsenftner wrote: post #56

I'm 15 years in writing high performance Internet servers in C++, and I can confirm higher level languages provide an illusion of capability, but once you're talking high performance with high compute requirements and scaling your service, the cost efficiency of C++ is exponential better than any other language. The higher level language ecosystems are bloated beyond repair. I was able to use one 32-core physical ser…

The thing that worries me about stories like this is that there is frequently (as is the case here) no mention any sort of HA or backups. No details on what disaster recovery looks like. Those are business critical considerations that cost money, and just disappear from the discussion when people say "hey i saved all this money dropping everything down to a single server!"

I am in the same boat (writing native servers). I will also "disappear" if you start asking me about HA/backups/etc. A particular solutions are very much case specific and can depend on business conducting rules just as much as on pure tech factors. Properly answering your question requires way too much writing and hardly a subject of a single post. I have HA solutions for the products I built but this post is the extent I am willing to talk about the subject ;)

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

#268

Post by wffurr »

sillysaurusx wrote: post #124
wffurr wrote: post #114

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.

Only use shared_ptr when you actually want shared ownership. If you stick to unique_ptr for owning references and then "borrow" that raw pointer in functions, then you get speed without sacrificing too much safety and still no new/delete.

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

#269

Post by brobdingnagians »

postpawl wrote: post #23
lewis1028282 wrote: post #17

Earlier quoted context omitted.

Not really IO is always going to be slow compared to the CPU. The Python interpreter will be blocked 90% of that time waiting for IO anyway.

Exactly, and I’m surprised none of the other comments mentioned this so far. Often web app endpoints are bottlenecked by IO because they’re spending most of their time talking to a database or cache server. Python is probably not the right tool for a CPU intensive endpoint that needs to serve up hundreds of thousands of requests per minute and can’t be cached. There are a lot of ways to handle the IO intensive scenar…

Sometimes the language is the reason it is IO bound. A good example of this and discussion is in the link below. The heap of abstractions can cause it to be IO bound, or the CPU usage can bound the IO.

https://erikengbrecht.blogspot.com/2008/06/what-does-io-boun...

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

#270

Post by einpoklum »

easytiger wrote: post #177
sumeno wrote: post #78

Earlier quoted context omitted.

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.

> Memory management in modern C++ is considerably easier than it used to be It was never actually an issue

... until you got the segmentation fault, that is.
Post reply on HN