←back to thread

Multi-Core by Default

(www.rfleury.com)
70 points kruuuder | 1 comments | | HN request time: 0.234s | source
Show context
bob1029 ◴[] No.45537650[source]
The thing I struggle with is that most userland applications simply don't need multiple physical cores from a capacity standpoint.

Proper use of concepts like async/await for IO bound activity is probably the most important thing. There are very few tasks that are truly CPU bound that a typical user is doing all day. Even in the case of gaming you are often GPU bound. You need to fire up things like Factorio, Cities Skylines, etc., to max out a multicore CPU.

Even when I'm writing web backends I am not really thinking about how I can spread my workload across the cores. I just use the same async/await interface and let the compiler, runtime and scheduler figure the annoying shit out for me.

Task.WhenAll tends to be much more applicable than Parallel.ForEach. If the information your code is interacting with doesn't currently reside in the same physical host, use of the latter is almost certainly incorrect.

replies(1): >>45537847 #
CJefferson ◴[] No.45537847[source]
I find async a terrible way to write interactive apps, because eventually something will take too long, and then suddenly your app jerks. So I have to keep figuring out manually which tasks need sending to a thread pool, or splitting my tasks into smaller and smaller pieces.

I’m obviously doing something wrong, as the rest of the world seems to love async. Do their programs just do no interesting CPU intensive work?

replies(3): >>45537970 #>>45538548 #>>45538758 #
1. pmontra ◴[] No.45538758[source]
Probably. In web development it's usually get data, transform data, send data. That's in both directions, client to server and viceversa. Transformations are almost always simple. Native apps maybe do something more client side on average but I won't bet anything more than a cup of coffee on that.