Live data from Hacker News

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

twitter.com

21–30 of 376 posts

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

#21

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…

Years ago I had someone on reddit arguing with me about whether or not the GIL existed and affected Matz Ruby (this was 10+ years ago).

This person was actively arguing with me about what it was. It's one of many battle stories for why I pretty much just assume everyone on reddit is stupid unless shown otherwise.

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

#22
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…

This and more opinions from the oracle certified java guru.

Which part are opinions?

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

#23

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…

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 scenario in python:

* Threading - Works with python libraries written in C, but now you need to add locks to your code to prevent race conditions. Not good for CPU heavy work because it’s switching context every ~100 instructions.

* Gevent - Requires minimal code changes, but it usually blocks when running code from python libraries written in C. This uses event loop style concurrency and automatically patches internal python libraries to switch context when IO occurs. This means less time spent unnecessarily switching context, so it can scale better than python’s threading.

* multiprocessing - Better for CPU intensive work, but requires more memory than other solutions. You don’t need to worry about race conditions since the processes are separate.

* asyncio - Requires code changes and using compatible libraries. It does event loop style concurrency that allows you to specify specifically when to switch context. Like with gevent, this means less time spent unnecessarily switching context.

* ...And there are probably a bunch of other ways I’m missing.

I’ve heard that this sort of stuff is simpler in Go.

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

#24
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…

This and more opinions from the oracle certified java guru.

From the HN guidelines for commenting (https://news.ycombinator.com/newsguidelines.html):

> Be kind. Don't be snarky.

> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email us and we'll look at the data.

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

#25

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.

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

#26
post #25

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.

Could you expand on this please?

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

#27
post #25

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.

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 serially.

I’ve seen a lot of people who are cocksure they know some contrarian “actually you can use threads” trivia about Python and just naively use the threading module or naively use the newish ThreadPoolExecutor stuff not realizing that no, in fact, it’s not somehow magically always GIL-avoiding to do so.

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

#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 counting system to keep some of our sanity, and to at least try to avoid the worst memory leaks.

This was an edge case, and for almost everything else you’re probably better off implementing it in something that handles memory for you. If performance is an issue, least try it in Go or Rust with a quick PoC before jumping the C++ wagon.

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

#29
post #26
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.

Could you expand on this please?

You could just call raw pthread functions, or a library which does that.

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

#30

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…

I think you misunderstand the training of many types of large statistical models. It’s almost always I/O bound (getting batches of data into memory or shipped to GPU) and the CPU bound part is intensely optimized SIMD matrix algebra operations.

The hard part is always that you have more data than can fit into memory, and need complex prefetch solutions to parallelize getting the next batch of data while one batch’s numerical linear algebra computation is in progress.

Many libraries handle this transparently for the user in an extension module, such as Keras & PyTorch.

I think it’s misleading to act incredulous that this is the bottleneck ... it doesn’t have anything to do with Python, GIL, etc. (and there are easy-to-maintain solutions for this in Python).

Post reply on HN