121–130 of 376 posts
Earlier quoted context omitted.
Out of curiosity, what is the field for which you find this to be true?
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
Earlier quoted context omitted.
Out of curiosity, what is the field for which you find this to be true?
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
This means people frequently need to reinvent their own reference counting mechanisms.
Rust does this right. Rc and Arc.
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…
http://web.archive.org/web/20111108170021/http://david.heine...
Earlier quoted context omitted.
Out of curiosity, what is the field for which you find this to be true?
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
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.
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.
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
> That means we transfer 55 TB data / month this isn't a lot. Helps that site is mostly text data. I know of a relatively small cloud security system that transfers petabytes/month to/from a handful of customers. 4 ingest pods, 8 pipeline pods, 7 time-series db servers, 2 sql servers
Earlier quoted context omitted.
There is a significant amount of question submission, commenting and voting going on on SO.
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.
Earlier quoted context omitted.
> 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 deali…
Otherwise another trick is to identify a call which uses extensions or releases the GIL once it goes into C.
Earlier quoted context omitted.
> How did you ensure those threads would actually execute concurrently? By having multiple concurrent IO requests from multiple threads? Can probably log detailed timestamps to see if IO requests were happening in parallel.
Summing lists isnt IO
I'm 15 years in writing high performance Internet servers in C++, and I can confirm higher level languages provide an illusion of capability, but once you're talking high performance with high compute requirements and scaling your service, the cost efficiency of C++ is exponential better than any other language. The higher level language ecosystems are bloated beyond repair. I was able to use one 32-core physical ser…