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

71–80 of 376 posts

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

#71

Post by celticmusic »

twic wrote: post #60
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.

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…

I don't necessarily think you're right here, but I do know the number of horror stories that have come out of Heroku over the years certainly validates the opinion.

I remember reading about their routing debacle and realizing just how much work went into trying to get ruby to scale.

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

#72

Post by avip »

avip wrote: post #25
fxtentacle wrote: post #10

Many people don't know about Python's GIL https://wiki.python.org/moin/GlobalInterpreterLock That's the reason why you need to go multi-process if you want to reach a similar level of concurrency in Python as multi-thread in C++. And that surely adds a lot of complexity. As a very practical example of this, TensorFlow has a dedicated page with advice on how to make the Python part that reads the files from disk less…

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.

Ok, I see some comments (rightfully) asking for less talk and more code.

# main.py

    import random
    from concurrent.futures import ThreadPoolExecutor as Pool

    items = [random.random() for _ in range(10 ** 7)]


    def run(items, n):
        step = len(items) // n
        with Pool(max_workers=n) as ex:
            res = [ex.submit(sum, items[i*step : (i+1)*step]) for i in range(n)]
        return sum(r.result() for r in 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 16` ; do python3 -m main $x ; done


    1       0.172
    2       0.170
    3       0.166
    4       0.155
    5       0.149
    6       0.142
    7       0.144
    8       0.140
    9       0.136
    10      0.135
    11      0.135
    12      0.137
    13      0.135
    14      0.136
    15      0.136
    16      0.136

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

#73

Post by ginko »

avip wrote: post #72
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.

Ok, I see some comments (rightfully) asking for less talk and more code. # main.py import random from concurrent.futures import ThreadPoolExecutor as Pool items = [random.random() for _ in range(10 ** 7)] def run(items, n): step = len(items) // n with Pool(max_workers=n) as ex: res = [ex.submit(sum, items[i*step : (i+1)*step]) for i in range(n)] return sum(r.result() for r in res) if __name__ == '__main__': import ti…

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

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

#74

Post by edgyquant »

rdtsc wrote: post #42
edgyquant wrote: post #33

Earlier quoted context omitted.

I'd like to see these 10 lines that supposedly avoid the problems with the GIL.

> I'd like to see these 10 lines that supposedly avoid the problems with the GIL. Spawn a thread and handle disk or socket IO requests there? You can get fancy and use a thread pool so maybe 15 lines of code. Not sure why you used the word “supposedly”. Threads have been in the standard library for a very long time.

>Threads have been in the standard library for a very long time.

Yes and still run the risk of running into GIL problems. You claim to have shown 10 lines to an interviewer that proved he was wrong about the GIL still being an issue and I've yet to see an example of it not being one when using pure python. Yes there are certain cases where you don't hit the GIL, no that doesn't mean it isn't still an issue when dealing with threads.

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

#75

Post by ww520 »

twic wrote: post #60
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.

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.

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

#77

Post by riyadparvez »

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

One thing to keep in mind that their work-load is very ready-heavy which eases things a lot when scaling the system. The same is true for Wikipedia. Scaling a write-heavy workload is way more complex than scaling a read-heavy workload.

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

#78

Post by sumeno »

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…

Memory management in modern C++ is considerably easier than it used to be. Bespoke memory managers aren't really needed, you can do almost anything you need to without ever using new or delete.

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

#79

Post by avip »

ginko wrote: post #73
avip wrote: post #72

Earlier quoted context omitted.

Ok, I see some comments (rightfully) asking for less talk and more code. # main.py import random from concurrent.futures import ThreadPoolExecutor as Pool items = [random.random() for _ in range(10 ** 7)] def run(items, n): step = len(items) // n with Pool(max_workers=n) as ex: res = [ex.submit(sum, items[i*step : (i+1)*step]) for i in range(n)] return sum(r.result() for r in res) if __name__ == '__main__': import ti…

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.

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

#80

Post by perl4ever »

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

At the risk of exposing my ignorance - look at all those "Peak 5%-20%" labels. Doesn't that mean they have a lot more than they need?
Post reply on HN