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

291–300 of 376 posts

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

#291

Post by gerbilly »

paulddraper wrote: post #205
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…

Web servers are usually trivially horizontally scalable. You must have had significant in-memory shared state to encounter that problem. Right? Had you adopted a less stateful model, you'd have looked rather pretty with two Java servers.

> Web servers are usually trivially horizontally scalable.

Maybe he really meant to say 'application server'. I.e that there was server side code with non trivial compute/memory requirements for running business logic.

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

#292

Post by draw_down »

decebalus1 wrote: post #106
IndrekR wrote: post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

> SO ranks #36 in Alexa right now It would rank way higher if they would be more webscale. It needs more Kubernetes, GraphQL and Golang /s

This joke was old 10 years ago. Find a new one already.

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

#293

Post by deanmoriarty »

avip wrote: post #220
pnako wrote: post #118

Earlier quoted context omitted.

I'm a casual Python programmer (just bit of scripting) and I had no particular misconception about the GIL; I don't care because I write single-threaded cookie cutter scripts. Your example I think is demonstrating the opposite of what you want to show. Those figures are atrocious.

The opposite of what? All I want is the GIL "discussion" to be based on facts rather than emotions, hyperboles and FUD. I'm not even sure what the opposite of that is.

What were the misconceptions of your interviewer you were trying to prove wrong with your POC of multiple threads summing a list?

The way I read your post, it seemed like your interviewer told you that threads in python are not effective for parallel computation because of the GIL, and your example proves exactly that. The performance of your threads are absolutely horrible, if you were to do that in C++/Java/Go you would likely see a speedup in the order of min(16, cores). Your example proves that your threads are exactly serialized during the computation, which I assume was the point of your interviewer (but please clarify my assumption).

Perhaps your interviewer was instead proposing that threads in Python work like a charm?

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

#294

Post by fock »

inetknght wrote: post #259
giantrobot wrote: post #224

Earlier quoted context omitted.

You have 250GB of "raw" data stored in CSV format. The parsed version of this data in memory is likely to be a fraction of the on-disk size. A `long` or `double` only take up eight bytes in memory but 10-20 bytes on disk stored as ASCII in a CSV file. Even if your raw data was 250GB you could store it in memory mapped files. A fast SSD can easily hit a gigabyte per second sequential read speed, far faster than your t…

> A fast SSD can easily hit a gigabyte per second sequential read speed, far faster than your typical network. It's important to note that often your disks aren't directly attached to your compute. That's frequently the case in (particularly cheap) cloud instances.

so, a hundred of the cheapest cloud instances cost you what? 1000 USD per month? You can easily get a deskside workstation for 10000 USD with a nice 2TB NVME-SSD, a 32-Core Threadripper and 128GB of memory... Utilization might be lower of course, but even if it's only utilized 8h/day this seems like a bargain for any solid business. For any startup aiming for exponential growth by burning through cash and having a 15month "half-life" this is not gonna work out though

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

#295

Post by zozbot234 »

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.

Even CPU is about "I/O" these days. Memory (RAM) is the new disk - and memory bandwidth is generally the performance bottleneck in heavy workloads, especially in multicore. This might be one reason why loosely 'C-like' languages like Rust are going back in style. High-level languages are terrible for memory bandwidth.

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

#296

Post by icebraining »

adrianN wrote: post #219
jsty wrote: post #188

Earlier quoted context omitted.

Out of curiosity - what's the source on that? Most figures I've seen put datacenter usage an order of magnitude lower: e.g. https://www.iea.org/reports/tracking-buildings/data-centres-... "Global data centre electricity demand in 2018 was an estimated 198 TWh, or almost 1% of global final demand for electricity (Masanet et al., 2018)."

This random site from I found by googling: https://www.insidescandinavianbusiness.com/article.php?id=35... I was surprised by that number myself, because I also thought that it was in the single digits.

It should be noted that report is talking about the client devices too - desktop, laptops, and even TVs. The datacenters part only accounted for 15% of that.

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

#297

Post by ycombobreaker »

tom_ wrote: post #48
CoolGuySteve wrote: post #40

Earlier quoted context omitted.

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.

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/

Most likely it is simply invoking a syscall (sbrk or mmap), which invokes the scheduler and may yield the time slice. Feed parsing code may not issue any other syscalls (entirely userspace), turning the allocation into a bit of russian roulette.

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

#298

Post by armitron »

Too wrote: post #228
ospider wrote: post #214

Earlier quoted context omitted.

Actually, Python is compiled to its bytecode and then interpreted by the Python VM, which is also how Java works. Python is slow because the lack of funds and people's focus, just take look at how fast JavaScript(V8) is nowadays.

No, Python bytecode is still interpreted at runtime. Java, JS and .NET is first compiled into bytecode but then they are also JIT-compiled into machine code which Python is not. You can JIT Python also using https://www.pypy.org/ but it's not the default and it's not 100% official and compatible.

It's also nowhere near as fast as other language JITs. I'm talking orders of magnitude slower than JVM, .NET and LuaJIT. End result being a - relatively - dead project, since the incentives for people to use it over stock Python and pay extra compatibility costs are not there.

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

#299

Post by vagab0nd »

inetknght wrote: post #223
hnews_account_1 wrote: post #132

Earlier quoted context omitted.

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 f…

> Are you saying this can be optimised to fit inside a single 10 core server in terms of compute loads? I'm currently employed to write software which does DNA analysis. DNA is known for being Big Data. Some applications are very compute intensive and others are very data-relation intensive. The very compute intensive applications process about 1GB of data in about 30 minutes on a 32 core Xeon 6xxx with 32GB of RAM a…

That's very interesting. Do you mind sharing some more details on what those computations are? Where can I learn more about these DNA analysis use cases?

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

#300

Post by paulddraper »

gerbilly wrote: post #291
paulddraper wrote: post #205

Earlier quoted context omitted.

Web servers are usually trivially horizontally scalable. You must have had significant in-memory shared state to encounter that problem. Right? Had you adopted a less stateful model, you'd have looked rather pretty with two Java servers.

> Web servers are usually trivially horizontally scalable. Maybe he really meant to say 'application server'. I.e that there was server side code with non trivial compute/memory requirements for running business logic.

By "web server", I meant (Java) "application server".
Post reply on HN