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

51–60 of 376 posts

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

#51

Post by rdtsc »

mlthoughts2018 wrote: post #27
avip wrote: post #25

Earlier quoted context omitted.

Many other people "know" about the GIL, to the extent of believing there's no point using threads in python "because of the GIL". I had a funny such experience lately in a job interview. I told the interviewer his misconception could be falsified with ~10 LOC summing a list with 2 threads.

How did you ensure those threads would actually execute concurrently? If any operations were GIL-bound (which is extremely common, even if not intentional, by reliance on bytecode instructions dealing with CPython API under the hood, like attribute lookups or iteration special methods), then execution is probably interleaved serially and constrained by the interpreter’s GIL allocation, and slower than just summing se…

> How did you ensure those threads would actually execute concurrently?

By having multiple concurrent IO requests from multiple threads? Can probably log detailed timestamps to see if IO requests were happening in parallel.

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

#53

Post by fatbird »

pizlonator wrote: post #9
fatbird wrote: post #3

Has Carmack looked at Rust? I'd be very curious for someone like him to look at it in light of his experience with C/C++ and high performance systems.

Good question, not sure why you were voted down. And I’m not even a Rust fan.

I was curious mainly because I remember some long comments he made about the relative value of linting and static analysis tools, specifically going into Coverity's analysis of the Doom 3 code (I think), fixing everything it flagged for some subset of the code, and then asking himself whether it was really better or more of a hindrance that obfuscated code.

IIRC, his conclusion was mixed: a lot of it was obviously beneficial and worth having turned on, but much of it wasn't, and going forward he intended to make it a limited but continual part of his toolchain.

So my interest in whether he'd tried Rust was whether he'd compared Rust's changes like the borrow checker against his earlier conclusions on writing good C/C++. Cute that he's tried and liked it, but I'd really like to see a more in-depth comparison from him.

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

#54

Post by IndrekR »

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

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

#55

Post by rdtsc »

avip wrote: post #25
fxtentacle wrote: post #10

Many people don't know about Python's GIL https://wiki.python.org/moin/GlobalInterpreterLock That's the reason why you need to go multi-process if you want to reach a similar level of concurrency in Python as multi-thread in C++. And that surely adds a lot of complexity. As a very practical example of this, TensorFlow has a dedicated page with advice on how to make the Python part that reads the files from disk less…

Many other people "know" about the GIL, to the extent of believing there's no point using threads in python "because of the GIL". I had a funny such experience lately in a job interview. I told the interviewer his misconception could be falsified with ~10 LOC summing a list with 2 threads.

> I had a funny such experience lately in a job interview. I told the interviewer his misconception could be falsified with ~10 LOC summing a list with 2 threads.

I had multiple of those experiences. Even then people wouldn’t believe me so we had to look at Python C code and read about threads and IO operations in C and such. The other alternative is to write a deliberately slow socket server that takes say 5 seconds to respond then then write a threaded client to issue requests and seeing how they complete in parallel.

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

#56

Post by bsenftner »

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 server running a C++ http server I wrote providing a rich media web service and replace an AWS server stack that cost my client 120K per month. The client purchased one $8K 32-core server and co-located it behind a firewall at a cost of $125 per month. And the C++ server ran at 30% utilization, plenty of room for user growth. Their AWS stack of a dozen C#, Python, PHP and Node apps were peaking their capacity too. If course, my solution caused existential questioning by the non-geek CEO and the CTO, but they were in crisis and needed to radically revise how they provided their service or close.

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

#57

Post by bsenftner »

jariel wrote: post #16
rvz wrote: post #13

> ...My bias is that a lot (not all!) of complex “scalable” systems can be done with a simple, single C++ server. The second tweet of the discussion: > JAVA or C# would also be close, and there are good reasons to prefer those over C++ for servers. Many other languages would also be up there, the contrast is with Really Slow (but often productive and fun) languages. I'm afraid that Carmack has sided with his own anec…

"But for the sake of Carmack's engineering background however, it is unsurprising why Java/C#/Kotlin are technically unsuitable for high-performance gaming platforms if one was to create one." This really is just not true. Financial, real-time style High Frequency Trading apps are often written in Java - not C++. Much of the JVM is not a VM, it compiles to machine code - in an optimised manner. For starters. Given ho…

The developer lie most have been hoodwinked to believe: "Given how difficult it is to develop safely in C++..."

No. That is high level language propaganda and simply not true.

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

#60

Post by twic »

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.

I semi-seriously think the entire modern shape of the cloud is a result of Ruby being really slow.

Back when people were writing their backend business apps in C++, COBOL, Java, etc, if there was ever a performance problem, you could usually just get a slightly bigger machine and grow your thread pools a bit. But once the web took off and Ruby exploded onto it, you couldn't do that, because it's an order of magnitude slower, and doesn't really do multithreading. But, as long as you follow twelve-factor discipline, it scales horizontally like a champ. So, we took to horizontal scaling over multiple VMs (and caching things in Redis instead of local memory or Hazelcast or whatever), and that's been the unquestioned way to do scaling ever since.

Post reply on HN