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

271–280 of 376 posts

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

#271

Post by filleokus »

ww520 wrote: post #241
shrimpx wrote: post #213

Earlier quoted context omitted.

It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.

Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?

In my experience this is only true iff the system never gets any more user facing features.

Every new non-insignificant feature requires a new REST-API route, or database table or modification of the GraphQL schema. And depending on how you designed the backend, even small redesigns of the frontend might require changes on the backend. Consider a simple app showing car rentals, where you initially have something like /car/[id], then the frontend guys realise that we need to show cars rented by each customer and it's necessary to have /customer/[id]/rentals.

(Of course it's possible to design a system without any schemas or normalisations, which would make your statement truer, but that's rarely attractive for other reasons.)

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

#272

Post by philipov »

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.

Not for everyone. In finance, a query might only use gigabytes or terabytes of data, but need to do a ton of simulation and calculation on top of that. Optimization of e.g. trading algorithms is entirely CPU-bound.

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

#274

Post by lonelappde »

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…

This was part of the excitement/promise of Go lang, to eliminate the need for small-scale mapreduce jobs, with library code that launched a year or two before the cost paper was published.

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

#275

Post by bane »

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.

This is true in a "water is wet" kind of way. The point is that a great many problems that can fit neatly into a single machine are being turned into I/O problems by being distributed onto clusters.

There's an incredible number of gigabyte and even terabyte scale problems that are consuming racks of blades when a little thinking and understanding of the problem being solved can be done pretty nicely on far fewer resources.

What's really happening is that to many people they think it's "easier" to simply rack more equipment into the cluster and end up shifting the complexity into cluster administration rather than programmer time.

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

#276

Post by filleokus »

otabdeveloper4 wrote: post #193
coderunner wrote: post #134

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.

No, it's not significant. Dev time depends on programmer skill, not the toolset. A good C++ programmer will develop your MVP many times faster than an average Python programmer. Python programmers are much easier to hire, though - you already need a good C++ programmer on the team to hire another one, because HR and corporate management can't into proper hiring process. This last factor is the overarching most import…

> Dev time depends on programmer skill, not the toolset.

This is obviously not strictly true, always. A skilled programmer will use the proper tools for the job.

If you for example is tasked with writing a backend service exposing a GraphQL API, I think it would be foolish to do this in C++, and would bet that the average Python programmer would do it quicker than even a top-tier C++ programmer (if the latter would be hellbent on doing it in C++).

Especially when working with MVP's (or new projects in general), the ability to leverage already existing tools and frameworks are key to rapid progress. This doesn't necessarily have to be scripting languages, but the Python/Node/Go/etc developer would have a working GraphQL server up and running connected to a database of choice within an afternoon while the skilled C++ developer would have to spend at least a few days implementing a GraphQL server mostly from scratch [0].

[0]: A quick Google show that schema parsers exists for C++, but nothing matching the frameworks/library available for more web-fashionable languages.

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

#277

Post by markus_zhang »

shakna wrote: post #200
onlyrealcuzzo wrote: post #179

Earlier quoted context omitted.

Old Reddit isn't slow. It seems to mostly be the new frontend.

Old Reddit is still slow, but not too bad. Reddit's new software stack is... Atrocious.

I recalled that back in the days when the new Reddit has been rolled out, there were quite a few days that it's difficult to open in mobile browser. Now it's much better.

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

#278

Post by CoolGuySteve »

cogman10 wrote: post #164
tom_ wrote: post #48

Earlier quoted context omitted.

Milliseconds ??! What causes that to occur? Though I suppose if they can take that long, avoiding them is an even better idea than it is normally... For constant time allocations, try TLSF: http://www.gii.upv.es/tlsf/

I'm not the op, but I'm guessing large amounts of fragmented memory is what causes that. It's one benefit of a gced language with compaction, allocations are typically bounded (except when they trigger a gc).

Except compaction can also take many milliseconds and come from different threads.

Writing a trading system in Java is harder than C++ imo because where before you had an allocation problem, now you have a multithreaded randomly stalling allocation problem.

Virtu did it but everything I’ve heard about it nullifies the benefits of using java in the first place.

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

#279

Post by drinfinity »

ww520 wrote: post #241
shrimpx wrote: post #213

Earlier quoted context omitted.

It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.

Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?

Try it. It might surprise you.

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

#280

Post by commandlinefan »

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.

> It is a price worth paying for better language ergonomics

Back around 2001 or so, I was hired at an online travel agency to assist in porting their entire system from C++ to Java. Management at the time was frustrated at how long it took to add new features in the C++ codebase - it could take months to get something working in some cases, and they blamed the programming language. Once we got everything working in Java, we found that we could, in fact, turn around feature requests much faster than they could in C++. The trade-off was performance problems: they (we) found that in the old C++ codebase, if you fucked something up, the whole thing crashed, and you had to fix it before you could get it to run. In Java, programmers could paper over their fuck-ups pretty easily so that they wouldn’t be noticed until they had created a snowball effect that caused everything to slow down. Since management was pushing for more features faster, they were incentivizing developers to do as little testing as possible and kick the can down the road. For the most part, management was OK with this: they just bought more, and more, and more servers to make up for the performance problems we were having from the quick-turnaround features they wanted.

Post reply on HN