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

61–70 of 376 posts

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

#61

Post by postpawl »

ummonk wrote: post #50
postpawl wrote: post #23

Earlier quoted context omitted.

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…

From what I’ve seen in production environments, Python has an uncanny ability to take tasks that should be IO- / server- bound and make them CPU-bound.

For sure, but often that’s a sign that you’re doing it wrong. Maybe those aggregations should be done in the database, maybe it should be cached, maybe you should do that in bulk with one request, maybe it should run in the background anyway, etc.

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

#62

Post by twic »

pleasecalllater wrote: post #49
jandrewrogers wrote: post #47

Many developers severely underestimate how much workload can be served by a single modern server and high-quality C++ systems code. I've scaled distributed workloads 10x by moving them to a single server and a different software architecture more suited for scale-up, dramatically reducing system complexity as a bonus. The number of compute workloads I see that actually need scale-out is vanishingly small even in indu…

Two. The number is two. You always need a backup server :)

I used to think that. But there are a couple of notable exceptions at either end of the latency spectrum.

If your latency requirements are slack, then you can get away with one machine, because you can reboot or reprovision it and carry on processing without meet your requirements.

If your latency requirements are tight, you don't have time to fail over anyway, so you might as well run one machine and make sure you can deal with failing to meet your requirements.

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

#63

Post by twic »

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…

> Financial, real-time style High Frequency Trading apps are often written in Java - not C++.

They're written in a very specific style of Java, where you take pains not to allocate, which looks a lot more like C++ than idiomatic Java. Operationally, strange rituals are followed to avoid recompilation or other otherwise normal runtime activity during trading hours. The app will be started on sunday night, and the team spends the week praying it doesn't need restarting during the week.

You can do HFT in Java, but it's a dancing bear.

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

#64

Post by jariel »

jiggawatts wrote: post #31
jariel wrote: post #16

Earlier quoted context omitted.

"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…

Trading apps generally process a small amount of data. Graphs are downright lightweight compared to what a 3D game pumps through. Generally, for a 3D game manual memory management and explicit data layout are critical. For example, it's common to use custom memory allocators with a region for each frame, a region for each loaded level, etc... This is then much cheaper to simply drop on the floor than any kind of obje…

Yes thanks for that but I think author was referring to game synch server not actual games. Synching minimal state data can use small data structures etc. But thanks though great comment.

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

#65

Post by numbernine »

aspaceman wrote: post #34
edgyquant wrote: post #33

Earlier quoted context omitted.

I'd like to see these 10 lines that supposedly avoid the problems with the GIL.

It still hits the problems, but it can still be better than single-threaded. That's the point of his comment. People say the GIL is bad so they throw the baby out with the bathwater and no longer use threads, which isn't very well-reasoned. Been a while since I've used Python, but as far as I remember the GIL only affects Python objects. So if you use Numpy for operations, you can avoid the GIL.

Can you give an example for your last sentence?

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

#66

Post by celticmusic »

ses1984 wrote: post #38
nine_k wrote: post #32

Earlier quoted context omitted.

The only point of using Python threads is to wait for I/O. Which, while limiting, is a huge use case, for network servers in particular.

Can't you also defer work to c extensions in threads?

I don't know the specifics of Python's C interfaces, but I know Ruby by default will cover all 3rd party extensions in the GIL for safety and you can release it upon entry into the extension using the C api. But doing so can be very dangerous if you're calling back into the Ruby core as you could inadvertently cause problems that the GIL was meant to protect you from.

I imagine Python works roughly the same.

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

#67

Post by vikram »

rdtsc wrote: post #51
mlthoughts2018 wrote: post #27

Earlier quoted context omitted.

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.

Summing lists isnt IO

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

#68

Post by vikram »

rdtsc wrote: post #42
edgyquant wrote: post #33

Earlier quoted context omitted.

I'd like to see these 10 lines that supposedly avoid the problems with the GIL.

> I'd like to see these 10 lines that supposedly avoid the problems with the GIL. Spawn a thread and handle disk or socket IO requests there? You can get fancy and use a thread pool so maybe 15 lines of code. Not sure why you used the word “supposedly”. Threads have been in the standard library for a very long time.

Summing lists != IO

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

#69

Post by panpanna »

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

Note that they use C# and ASP.Net...

(SO and DailyWTF are very much into Microsofts ecosystem)

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

#70

Post by celticmusic »

postpawl wrote: post #61
ummonk wrote: post #50

Earlier quoted context omitted.

From what I’ve seen in production environments, Python has an uncanny ability to take tasks that should be IO- / server- bound and make them CPU-bound.

For sure, but often that’s a sign that you’re doing it wrong. Maybe those aggregations should be done in the database, maybe it should be cached, maybe you should do that in bulk with one request, maybe it should run in the background anyway, etc.

or maybe you should consider using C++, C#, Java, et al instead?
Post reply on HN