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

231–240 of 376 posts

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

#231

Post by eb0la »

qaq wrote: post #218

Keep in mind a modern commodity x86 server with 128 physical cores 4 TB RAM and decent amount of SSD storage and dual 100 gbe nics is about 70K. Ability to use something like Rust also changes equation significantly.

I believe the key is able to use something _native_, not interpreted code or bytecode, running on a virtual machine, which runs in a userspace process inside a virtualized server inside a bare metal server.

Said that, I believe Rust has a great future in data processing. Just take a look at Apache Arrow Rust bindings and Ballista (https://news.ycombinator.com/item?id=20456273)

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

#232

Post by pushpop »

Retric wrote: post #127
yawn wrote: post #105

Earlier quoted context omitted.

A slim subset of humans typing things is not what I would label "write heavy". Write heavy is more like 100k+ devices out in the field sending their current position every 10s. That's still very manageable, but requires some thoughtful design.

10k simple updates per second is hardly high bandwidth. I knew people handling similar workloads on a 1U server 10 years ago.

Indeed and I literally was. And the back end was written in mod_perl (which isn’t exactly known for performance). Even back then 10k/s was our smallest service - both on income as well as traffic - so there wasn’t the incentive to rewrite it in a faster language.

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

#233

Post by Too »

pkolaczk wrote: post #194
Const-me wrote: post #140

Earlier quoted context omitted.

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

While I agree they can sometimes compete in numerically heavy tasks, the place where they fall behind is memory management. Systems like databases need very careful memory management and GC is not always your friend there. I'm still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language, although I'm not sure it is at all possible.

Rc/shared_ptr comes pretty close to GC from usability point of view?

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

#234

Post by otabdeveloper4 »

cthalupa wrote: post #217
otabdeveloper4 wrote: post #191

Earlier quoted context omitted.

Yes, if by "optimizing programmers" you mean "optimizing the manager's corporate structure footprint and bonus incentives". If the choice is between hiring one good C++ programmer or 15 really dumb Python "backend engineers" (and a team of QA's and sysadmins to support them), what do you think your pointy-hared corporate boss would chose?

This is a false dichotomy. You don't have to choose between 1 C++ developer and 15+ package of Python developers. Personal productivity is generally going to be slower in C++ than it is in Python. In most situations you would gain more productivity out of a similarly skilled Python dev as you are a C++ dev, so you'd probably need to hire more C++ developers. Unless your argument is "C++ devs are smart and Python devs…

> Personal productivity is generally going to be slower in C++ than it is in Python.

No, it entirely depends on the skill and experience level of the programmer.

> In most situations you would gain more productivity out of a similarly skilled Python dev as you are a C++ dev

No, a good programmer with equally good knowledge of both languages will code equally fast in both.

> This is a false dichotomy. You don't have to choose between 1 C++ developer and 15+ package of Python developers.

You failed to see the point. Large teams of clueless programmers doing things slowly and badly is a feature of the system, not a bug. KPI's for managers don't include lowering headcount and cost cutting as an incentive. (And trust me, you really wouldn't like it if they did.)

> Unless your argument is "C++ devs are smart and Python devs are dumb", in which case, let's not start calling people names over the language they use.

Yet that's effectively what you just did in your specious 'productivity' argument.

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

#235

Post by jiggawatts »

jariel wrote: post #64
jiggawatts wrote: post #31

Earlier quoted context omitted.

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.

If anything the server-side coding is harder. Many games do the full physics/simulation on the server to minimise cheating, and have to simulate from every player's perspective. Meanwhile the clients have a single perspective and most of the computation effort is offloaded to the GPU.

Additionally, most multiplayer games have the same codebase for the server and the client for the obvious reasons. Single player is literally "online play" with an in-memory channel to a local server.

All Quake-based games work this way, including the derivative Source-based games and a bunch of other engine variants. Unreal works this way too if I remember correctly.

You can't realistically write a client in C++ and a server in Java. You'd be practically doubling your development time!

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

#236

Post by growse »

jpz wrote: post #181
sriram_malhar wrote: post #141

This is precisely the point made by McSherry, Isard and Murray in their lovely paper, "Scalability! But at what COST?" (Usenix HotOS '15). They demonstrate how much performance headroom there is in modern CPU and memory, and show how simple cache-sensitive batch algorithms running on a single core can outperform hundreds of cores running distributed map-reduce style jobs. https://www.usenix.org/system/files/conferenc…

Big data is about I/O not CPU I’m a C++ veteran btw and understand the point but big data is about how to process petabytes of I/O not how to consume CPU.

> Big data is about I/O not CPU

> I’m a C++ veteran btw and understand the point but big data is about how to process petabytes of I/O not how to consume CPU.

I'm not sure this is cut-and-dry. Back when I was working on Spark workloads, there was some interesting research being done on where the bottlenecks were for jobs. I think it turned out for a lot of jobs, infinite disk / network io didn't give as much of an improvement as you'd expect.

https://databricks.com/session/making-sense-of-spark-perform...

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

#237

Post by PedroBatista »

useful wrote: post #192

PCI-e 4.0 and 5/6 enables consuming absolutely insane amounts of data. I can't think of many applications that need that. 128GB/sec? sure! and 256GB/sec is coming. With 10Gb, 40Gb and 100Gb internet links becoming mainstream the roadblock to having cool stuff is developers to make it.

Hold my beer, I’m firing up my [ insert dev stack ].

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

#238

Post by FpUser »

tlb wrote: post #155
wiradikusuma wrote: post #148

Earlier quoted context omitted.

But nobody in BigCo(tm) would do that, because everyone (including the executives) involved want to have Hadoop/BigData(tm) in their resume. /sarcasm

No doubt there are people who do it for cynical reasons. But at least some people do it sincerely thinking it’s the right choice. It’d be more interesting to talk about them, and how they came to make the wrong decision for what they thought were the right reasona.

Talked to many people lit you mentioned. Large percentage repeats these points:

1) We always wait for database, so performance of our code does not matter. This comes from places where ironically the whole database can fit into RAM. 10+ gbps connectivity - well it is almost commodity for business so the latency is not much of a bottleneck. Fast IO to store data - well imagine array of Optane drives. Not very cheap but really peanuts for normal business. All this means that purposely built data server which is a heart of many type of business residing on decent computer, can be blindingly fast and most of the businesses will never ever outgrow it. I've written quite a few of such servers serving loads of businesses in NA so hopefully my experience is not irrelevant.

2) Scripting languages are so convenient to use and save so much time and this is what matters as the salary is a main expense. - Personally I use those mostly for management/deployment/etc.etc type of scripts and maybe to quickly test some small ideas. I clearly see their benefits there. Anything that resembles a product that would actually run business. Sorry but experienced developer can implement those just as fast as in any scripting language and it will save a ton on maintenance.

3) And finally do not do premature optimization mantra . - In my opinion switching from scripting language to something like C++ has nothing to do with premature optimization. Developer can be very productive with compiled languages as they also have megatons of libraries for any imaginable task.

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

#239

Post by angrais »

buzzkillington wrote: post #216
jacobsenscott wrote: post #196

Earlier quoted context omitted.

You never choose to hire dumb programmers. The choice is between 15 good cpp programmers and 4 good python programmers.

You have not had to interview the python devs I've had to interview. Last round, for the second best candidate who we hired at 130% the salary we initially offered, after the best candidate was snatched under our nose for what we were told was twice the salary we were offering: >"Last question, I saw that you wrote a 100 line function here, is this because you ran out of time?" >>"No. I don't like to break up my func…

That sounds more like someone unfamiliar with good practices generally than python-specific issues.

Also ... Why'd you hire this person? Is there such a lack of "good" developers in your area?

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

#240

Post by golergka »

ww520 wrote: post #75
twic wrote: post #60

Earlier quoted context omitted.

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…

The push for the need of scaling out started with Ruby and Python's lack of performance. The reason being pushed at the time was, "developer time was more expensive than hardware." Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed.

> Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed.

I'll bite. I think it actually counts not only that, but also the probability that the product will actually get to be developed, and not need to significantly pivot, therefore throwing all developer time spent on perfomance to garbage.

Post reply on HN