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

321–330 of 376 posts

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

#321

Post by chusk3 »

pkolaczk wrote: post #190
pnako wrote: post #113

Earlier quoted context omitted.

I've seen state-of-the-art low-latency trading software written in C# or Java. You should not be doing any memory allocation in the critical path anyway, so garbage collection is hardly a relevant factor.

Having written lot of Java, Scala and C++ (and recently some Rust), I must say it is much easier to avoid heap allocations in C++ and Rust than in GCed languages, thanks to explicit allocation on the stack and pass by value + move semantics.

A big push in .net core 2.x and 3.x was what we call the Span-ification of the base class library and the runtime. This means there are many new APIs for dealing with slices of memory in a non-allocating manner, and this combined with memory pooling has contributed greatly to an overall performance boost to the runtime by reducing copying and GC time. These same APIs are available to the developer so I'd imagine that it would be simple to build a non allocating network buffer reader. I have built a non-allocating video renderer before using the new APIs, for example.

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

#322

Post by pjmlp »

panpanna wrote: post #251
FpUser wrote: post #248

Earlier quoted context omitted.

Anything wrong about that?

No, I'm just pointing out that they are different from your average SV company.

However they are quite average regarding typical European corporate stacks, either Java or .NET.

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

#323

Post by jjeaff »

fock wrote: post #286
RhodesianHunter wrote: post #150

Earlier quoted context omitted.

They said read heavy, not read only. I guarantee you the bulk of traffic to SO is hitting a page and performing zero writes.

so, would you mind showing any non-FANG, but write heavy site? Besides that, even the operation of most social networks should be very easy to be split into town-sized instances with batch-updates in-between instances (see mastodon specs https://github.com/tootsuite/documentation/blob/master/Runni... ). What actually costs a lot is constantly surveilling all user interactions, data-warehousing that and playing out ad…

Most any saas offering is going to be very write heavy in comparison.

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

#324

Post by slavik81 »

wffurr wrote: post #268
sillysaurusx wrote: post #124

Earlier quoted context omitted.

This is the quickest way to kill your performance in C++. I guarantee it wasn’t what Carmack was talking about. I used sharedptr extensively in a game engine. Whoops: suddenly 20% of the frame time was gone, never to be recovered. Once that performance is gone it’s almost impossible to get it back, short of rewriting every system.

Only use shared_ptr when you actually want shared ownership. If you stick to unique_ptr for owning references and then "borrow" that raw pointer in functions, then you get speed without sacrificing too much safety and still no new/delete.

Additionally, shared ownership should be rare. Most objects should have a single owner that is responsible for them. This is not only better for performance, but also makes the system easier to understand.

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

#325

Post by ncmncm »

pnako wrote: post #113
8fingerlouie wrote: post #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 cou…

I've seen state-of-the-art low-latency trading software written in C# or Java. You should not be doing any memory allocation in the critical path anyway, so garbage collection is hardly a relevant factor.

A trading system in C# or Java is not, practically by definition, state-of-the-art. To suggest otherwise just demonstrates not knowing the State of the Art.

"Capable" is plausible.

Sorry, I doesn't make the rules.

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

#326

Post by avip »

deanmoriarty wrote: post #293
avip wrote: post #220

Earlier quoted context omitted.

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…

2 things:

1. There is a common misconception that any threaded python code is slower than sequential. This is trivially false for IO-bound, and possibly, potentially, in some cases false for CPU-bound. Said interviewer had that very misconception.

2. More importantly - you and another parent are right. The code does not demonstrate what I thought it does. This is proven by removing the ThreadPool and leaving the code intact:

    import random
    import math
    from concurrent.futures import ThreadPoolExecutor as Pool

    items = [random.random() for _ in range(math.factorial(11))]


    def run(items, n):
        step = len(items) // n
        res = [sum(items[i*step : (i+1)*step]) for i in range(n)]
        return sum(res)

    if __name__ == '__main__':
        import timeit
        import sys
        n = sys.argv[1] if len(sys.argv) > 1 else 1
        time = timeit.timeit('run(items, %s)' % n, 'from __main__ import run, items', number=10)
        print("%s\t%.3f" % (n, time / 10))


    $ for x in `seq 1 11`; do python3 -m main $x ; done
    1       0.799
    2       0.749
    3       0.671
    4       0.715
    5       0.730
    6       0.704
    7       0.649
    8       0.631
    9       0.689
    10      0.613
    11      0.616
This is a result I'd have to silently contemplate before making any further comments.

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

#327

Post by [deleted] »

cthalupa wrote: post #265
otabdeveloper4 wrote: post #234

Earlier quoted context omitted.

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

>No, it entirely depends on the skill and experience level of the programmer. We're comparing programming languages. You control for the other variables - otherwise the comparison is meaningless. My argument is equally skilled programmers will generally be more productive in Python than C++. >No, a good programmer with equally good knowledge of both languages will code equally fast in both. Care to explain how? Huge…

[deleted]

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

#328

Post by erik_seaberg »

kick wrote: post #317
zozbot234 wrote: post #290

Earlier quoted context omitted.

What specific ergonomics pitfalls did you experience in Rust? "Development velocity is too slow" is a bit vague; beyond the use of GC, which only really matters in specialized domains, there's not much reason to think that rewriting your service in Go would give you better 'development velocity'.

There is, though. Go was designed to be easier to reason with than conventional ALGOL-derivatives, while Rust wasn't. To quote Rob Pike: The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use the…

If you can write a ton of code without thinking very much, you're probably writing boilerplate that should have been generated from a human-level description of the problem. Your job is to only spend time writing what needs to be written.

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

#329

Post by cogman10 »

CoolGuySteve wrote: post #278
cogman10 wrote: post #164

Earlier quoted context omitted.

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.

Newer Java GCs are very low latency (microsecond). You trade performance and memory for that low latency though. AFAIK, they are still compacting.

Still though, probably makes sense to do it in a lower level language. It's just far easier in C++ to decide that "Hey, you know what, I just want a big memory block that I control".

I've even heard of game devs doing things like having per frame allocators. They get super fast allocation because they just pointer bump and at the end they simply reset the pointer back to location 0. I'm sure trading systems could do something similar.

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

#330

Post by kick »

zozbot234 wrote: post #319
kick wrote: post #317

Earlier quoted context omitted.

There is, though. Go was designed to be easier to reason with than conventional ALGOL-derivatives, while Rust wasn't. To quote Rob Pike: The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use the…

> Go was designed to be easier to reason with than conventional ALGOL-derivatives, while Rust wasn't. This may be a problem of what's idiomatic in each language, as opposed to a matter of language design per se. After all, Rust development can be made at least as easy as, e.g. Swift, simply by adding enough uses of .clone() and RefCell . Is this suboptimal? Of course, but it will still be plenty faster than Python, a…

This may be a problem of what's idiomatic in each language, as opposed to a matter of language design per se.

It's absolutely a matter of language design. Again, I'm not criticizing Rust, but a language explicitly designed to be trivially written by anyone, fast, is going to be easier to write in quickly by anyone. Imagine making that comment about Logo instead of Go. Of course Logo is more painless to write than Rust! It's a child's language. So is Go!

Rust development can't be made as easy as Swift (and it is very unlikely that what you described would be faster than Go). Even Graydon Hoare agrees that Rust is inadequate in comparison to Swift in terms of development ease:

https://www.reddit.com/r/rust/comments/7qels2/i_wonder_why_g...

I'm no stranger to languages with vastly different idioms than normal (I write APL daily), but not all languages are as quick to develop in as every other, and pretending they are is silly. Rust has some innovations, and it's by no means a bad language in itself, but pretending it wins at everything under the sun (even things it's not trying to do) doesn't reflect reality or the perspective of the original author.

Post reply on HN