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

31–40 of 376 posts

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

#31

Post by jiggawatts »

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…

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 object-by-object cleanup, whether that is reference counting, garbage collecting, a traditional heap, or whatever. Even Rust can't yet compete with this!

Similarly, many game engines use ECS systems or in-memory columnar data layout to (structure of arrays instead of arrays of structures) to enable SIMD instruction sets such as AVX.

Java can be coerced into doing much of the above, but it generally takes a ridiculous effort to approach what comes nearly effortlessly with a language like C++ or Rust.

Even C# is a better choice than Java, as it monomorphises more code and recently had a range of extensions[1] added to reduce GC pressure such as stackalloc, Span, Memory, MemoryPool, SequenceReader, ValueTask, etc...

I've bought and played several games written in C#, but other than Minecraft I'm not aware of any popular real-time games written in Java in the last 15 years or so. Meanwhile, Minecraft is not at all smooth on my very high end gaming PC in 2019 despite being 8 years old. (I'm sure this can be eliminating by tweaking some settings, but it's indicative of the problem.)

I say this as someone who used to professionally develop browser-based Java games back in the early 2000s and had to personally jump through hoops to reduce heap allocations to avoid GC pauses.

[1] https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/...

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

#32

Post by nine_k »

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.

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.

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

#33

Post by edgyquant »

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'd like to see these 10 lines that supposedly avoid the problems with the GIL.

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

#34

Post by aspaceman »

edgyquant wrote: post #33
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.

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.

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

#35

Post by wruza »

Morals of this story: 1. Always use the most performant language available to you. (What if your program gets a few million users?)

2. Horizontal scalability is too much complexity/work. Just apply the correct amount of optimization when you initially write the code.

If you, like me, read this on mobile and did not click [more answers] link under that, then do it. That may save you a minute or two of derealization time.

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

#36

Post by api »

This has been a repeated point since "enterprise" Java (a.k.a. Jabba) became a thing in the late 90s and early 2000s. A ton of enterprise code is comically inefficient and held together with scotch tape and used chewing gum.

It ends up boiling down to the fact that compute power is a lot cheaper than developer time and really good developers are more expensive and harder to find than inexperienced ones.

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

#37

Post by choeger »

wruza wrote: post #35

Morals of this story: 1. Always use the most performant language available to you. (What if your program gets a few million users?) 2. Horizontal scalability is too much complexity/work. Just apply the correct amount of optimization when you initially write the code. If you, like me, read this on mobile and did not click [more answers] link under that, then do it. That may save you a minute or two of derealization ti…

I really had a hard time to decide whether I agree with that statement or not. If you design a whole service it is obviously not true. But if you develop something like a specialized Backend, say a database, you might want to reconsider the complexity of horizontal scalability.

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

#38

Post by ses1984 »

nine_k wrote: post #32
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.

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?

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

#39

Post by choeger »

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…

But aren't the edge cases the things that satisfy your pay? The standard cases of today are the introductory examples of tomorrow and will be automated or abstracted away by the end of next week. In JavaScript.

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

#40

Post by CoolGuySteve »

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…

If you're parsing market data then you shouldn't really be allocating at all once the initial setup is complete. So there shouldn't be a need for ref counts.

This is because the allocator itself can have an unbounded runtime that takes milliseconds, causing you to drop.

In the past I've replaced malloc with an implementation that asserts if called on certain threads after init time.

Post reply on HN