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

131–140 of 376 posts

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

#131

Post by reitzensteinm »

avip wrote: post #79
ginko wrote: post #73

Earlier quoted context omitted.

That’s not exactly what I would call good speedup.

The point of the code is not to speedup the execution of summing a list of random number, but rather to speedup the acknowledgement of N random python developers that they have some misconceptions about the GIL. I think it does that pretty well but, well, that's just like my opinion.

I feel like you're beating a strawman. Using threads to speed up IO in Python is common, and for computation heavy work the fear of the GIL is 100% justified, as your example shows.

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

#132

Post by hnews_account_1 »

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…

Can you expand on this? I have some pretty massive compute loads that need to be scaled onto a cluster with 100+ workers for most computations. This is after I use a library called dask that graphically does its own mapreduce optimisation inside its modules. This is all for a relatively small 250GB raw data file that I keep in a csv (and need to convert to SQL at some point).

Are you saying this can be optimised to fit inside a single 10 core server in terms of compute loads?

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

#133

Post by betaby »

lmm wrote: post #117
steev wrote: post #112

Earlier quoted context omitted.

This sounds like an architecture problem, not a language problem. Can you elaborate?

Of course it's possible to write a horizontally scaled application in Java or C++. But once you have to deal with horizontal scaling anyway , language performance is much less of an advantage: as Carmack says, the difference between 100 servers and 10 is just accounting.

And the difference between 1000 servers and 100 is not just accounting. In essence, 1 full rack is easy to reason about while N>1 is not, for myriads of non accounting reasons.

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

#134

Post by coderunner »

What about in the context of trying to get to an MVP? Is the dev time speedup of using a dynamic programming language and stack significant over using a c++ backed? You wouldn't care much about performance when you're trying to figure out if you'll get traction.

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

#135

Post by winrid »

steev wrote: post #112
lmm wrote: post #111

Horizontal scalability carries a lot of overhead. Probably a factor of 10, easily. But the clue is in the name: eventually you'll get to a point where you have to scale. Back in 2010 I worked for a company whose system, in Java, ran on a single web server (with one identical machine for failover). We laughed at our nearest rivals, who were using Ruby, and apparently needed 60(!) machines to run their system, which ha…

This sounds like an architecture problem, not a language problem. Can you elaborate?

Sounds like they had their datastore as part of the application. So only way to scale it would be to write a distributed data store... Or rewrite the app :p

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

#136

Post by [deleted] »

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.

[deleted]

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

#137

Post by mberning »

kyledrake wrote: post #7

The analogy here is one of the best ice climbers in the world proposing an ascent of the Matterhorn. Please use testable, easy to prototype with, memory managed languages for production servers unless you are solving a very specific problem and really know what you are doing.

Very apt. I think people are also forgetting “the bad old days” where you worked on a large-ish cpp or java app for a year, nothing worked right, schedules slipped, and then the whole thing was scrapped and teams disbanded to work on other stuff. That was very common. You can’t count on having a team of Carmacks work on your blub app.

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

#138

Post by aspaceman »

numbernine wrote: post #65
aspaceman wrote: post #34

Earlier quoted context omitted.

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?

Here's a link: https://scipy-cookbook.readthedocs.io/items/ParallelProgramm... And a quote in italics below.

And, more importantly for us, while numpy is doing an array operation, python also releases the GIL. Thus if you tell one thread to do:

  print "%s %s %s %s and %s" %( ("spam",) *3 + ("eggs",) + ("spam",) )
  A = B + C
  print A
During the print operations and the % formatting operation, no other thread can execute. But during the A = B + C, another thread can run - and if you've written your code in a numpy style, much of the calculation will be done in a few array operations like A = B + C. Thus you can actually get a speedup from using multiple threads.

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

#139

Post by j88439h84 »

sumeno wrote: post #84
kitsuac wrote: post #2

I've been programming C++ and assembly for 23 years. Few years ago I became a huge fan of Python. In my opinion Python is amazingly well suited for rapid first revision and can then be swapped out for C++ / asm.

This is fine as long as you can convince management to spend the money to rewrite your software. That's usually a hard sell though. In my experience this plan usually ends up with a python monstrosity that everyone hates but is forced to deal with forever.

Type hints and dataclasses are a game-changer for Python. Much easier to reason about programs that use them.

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

#140

Post by Const-me »

lmm wrote: post #109
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.

The idea that GCed languages in general have Python-like performance is a dangerous myth. Languages that are managed but not interpreted (e.g. Java, OCaml, Haskell, C#, Swift) have performance characteristics that are much closer to C than to Python.

This.

Modern C# in net-core 3 can even match C++ at manually vectorized numeric code: https://github.com/dotnet/coreclr/issues/27909#issuecomment-...

Post reply on HN