Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multi-Core by Default

rfleury.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Multi-Core by Default

#41

Post by jayd16 »

rcxdude wrote: post #36
jayd16 wrote: post #25

Earlier quoted context omitted.

I guess you can argue that instruction reordering, SMT/Hyper-threading are already eating the easy wins there. And as you said, it seems like the gains taper off at 2x. I'm not sure why games would be a good target. They're traditionally very much tied to a single thread, because ironically, passing data to the graphics and display hardware and to multi threaded subroutines like physics all has to be synchronized. Th…

Yeah, ECS is the approach I've heard can get games to have sufficient parallelism. Though only if you are careful about sticking to it properly, and with careful management of the dataflow between systems. I think the main thing is, apart from the difficulty of doing the analysis in the first place, if you're writing the code without thinking about parallelism, you will tend to introduce data dependcies all over the…

Agreed. It exemplifies what parallelism is on the table but also how many more guarantees need to be enforced to get it.

You're almost swinging the pendulum back to a fixed pipeline and I don't think you can get that for free.

Re: Multi-Core by Default

#42

Post by vitaminCPP »

keith_analog wrote: post #34

The article makes for an interesting technical read, and points to some very important issues, such as debugging in a multicore environment. Even so, I encourage anyone reading this article to keep in mind that there is a massive amount of work dedicated to software support for multicore parallelism. For anyone interested in digging deeper into multicore parallelism, I recommend taking a look at the CMU approach to t…

> they do it using either a parallel functional language or a parallel library in modern C++.

IMO this is a weakness not a strength. The approach of Fleury (low level C, no lib), makes his articles a lot more valuable for understanding fundamentals.

Re: Multi-Core by Default

#43

Post by vitaminCPP »

jt2190 wrote: post #10
rfleury wrote: post #8

Earlier quoted context omitted.

Those interested can go look at all of the actual code I’ve written using these techniques, and decide for themselves whether or not it’s practical only for “simple sub tasks or basic CLI tools”: https://github.com/EpicGamesExt/raddebugger/blob/c738768e411... https://github.com/EpicGamesExt/raddebugger/blob/master/src/...

Posting a tl;dr here might stave off some of dismissive comments based only on only reading the headline.

This is a good advice. That said, I don't think you should care about people that comments on articles without reading them.

Re: Multi-Core by Default

#44

Post by nemothekid »

CJefferson wrote: post #17
CaptainOfCoit wrote: post #9

Earlier quoted context omitted.

Are you using multiple threads or just a single one? Not sure why your application would "jerk" because something takes long time? If it's in a separate thread, it being async or not shouldn't matter, or if it's doing CPU intensive work or just sleeping.

If I’m using threads for each of my tasks, then why do I need async at all? I find mixing async and threads is messy, because it’s hard to take a lock in async code, as that blocks other async code from running. I’m sure this can be done well, but I failed when I tried.

You can map N-async tasks onto M-threads. This is essentially what Rust does, and if you squint this is how Go works as well.

A go routine is not that different from an async task, except the runtime inserts all the await points for you.

Re: Multi-Core by Default

#45

Post by ericbarrett »

zackmorris wrote: post #38
jerf wrote: post #19

If the author has not already, I would commend to them a search of the literature (or the relevant blog summaries) for the term "implicit parallelism". This was an academic topic from a few years back (my brain does not do this sort of thing very well but I want to say 10-20 years go) where the hope was that we could just fire some sort of optimization technique at normal code which would automatically extract all th…

One thing that might help is that state space explosion is mainly caused by mutability. Because each mutation potentially creates branching that can be difficult or impossible to statically analyze. In other words, imperative programming with const is directly transpilable to/from functional programming. Using modern techniques like higher order methods, scatter-gather arrays (similar to map-reduce), passing by value…

> Using modern techniques like higher order methods, scatter-gather arrays (similar to map-reduce), passing by value via copy-on-write, etc, code can be written that works like piping data between unix executables. Everything becomes a spreadsheet basically.

I have built a decent amount of multithreaded and distributed systems. I agree in principle with everything you wrote in that paragraph. In practice, I find such techniques add a lot of unstable overhead in the processing phase as memory is copied, and again while the results are merged, conflicts resolved, etc. They also lock you into a certain kind of architecture where global state is periodically synchronized. So IMO the performance of these things is highly workload-dependent; for some, it is barely an improvement over serialized, imperative code, and adds a lot of cognitive overhead. For others, it is the obvious and correct choice, and pays huge dividends.

Mostly I find the benefit to be organizational, by providing clear interfaces between system components, which is handy for things developed by teams. But as you said, it requires developers to understand the theory of operation, and it is not junior stuff.

Completely agree that we could use better language & compiler support for such things.

Re: Multi-Core by Default

#46

Post by seabrookmx »

CJefferson wrote: post #17
CaptainOfCoit wrote: post #9

Earlier quoted context omitted.

Are you using multiple threads or just a single one? Not sure why your application would "jerk" because something takes long time? If it's in a separate thread, it being async or not shouldn't matter, or if it's doing CPU intensive work or just sleeping.

If I’m using threads for each of my tasks, then why do I need async at all? I find mixing async and threads is messy, because it’s hard to take a lock in async code, as that blocks other async code from running. I’m sure this can be done well, but I failed when I tried.

It depends what framework/language you're using.

It's messy in something like Python, but mostly transparent in C#. In C# you effectively are using async/await to provide M-N threading ala. GoLang, it's just different syntax.

OP references the C# method Task.WhenAll so they might be assuming other languages are equally capable.

Re: Multi-Core by Default

#47

Post by Izikiel43 »

jerf wrote: post #19

If the author has not already, I would commend to them a search of the literature (or the relevant blog summaries) for the term "implicit parallelism". This was an academic topic from a few years back (my brain does not do this sort of thing very well but I want to say 10-20 years go) where the hope was that we could just fire some sort of optimization technique at normal code which would automatically extract all th…

> would automatically extract all the implicit parallelism in the code and parallelize it, resulting in massive essentially-free gains.

Sounds like what mojo is attempting to do:

https://www.modular.com/mojo

Re: Multi-Core by Default

#48

Post by jandrewrogers »

I think a common blindspot that makes it difficult to fully take advantage of modern silicon is making distinctions between parallelism and concurrency in code that are in actuality ambiguous.

The canonical overly reductive examples are parallelism as trivial SIMD loop parallelism and concurrency as multiple threads working on different but related tasks. If those are your only models the opportunities will be limited. Parallelism, in the sense of executing multiple physical operations in a single instruction, is not limited to e.g. an arithmetic operation on arrays of numbers. If you can execute semantically orthogonal threads of logic in the same instruction, you arguably have both concurrency and parallelism at the same time.

For example, one of the most effective models for using AVX-512 is to treat registers as specialized engines for computing on 64-byte structs, where the structs are an arbitrary collection of unrelated types of different sizes. There are idiomatic techniques for doing many semantically orthogonal computations on the fields in these structs in parallel using the same handful of vector instructions. It essentially turns SIMD into MIMD with clever abstractions. A well-known simple example is searching row-structured data by evaluating a collection of different predicates across any number of columns in parallel with a short sequence of vector intrinsics. Query performance is faster than columnar for some workloads. For most code there is substantially more parallelism available within a single thread of execution than you'll see if you are only looking for trivial array parallelism. It is rare to see code that does this but the gains can be large.

On the other hand, I think concurrency is largely a solved problem to the extent that you can use thread-per-core architectures, particularly if you don't rely on shared task queues or work stealing to balance load.

Re: Multi-Core by Default

#49

Post by taeric »

CaptainOfCoit wrote: post #9
CJefferson wrote: post #7

Earlier quoted context omitted.

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?

Are you using multiple threads or just a single one? Not sure why your application would "jerk" because something takes long time? If it's in a separate thread, it being async or not shouldn't matter, or if it's doing CPU intensive work or just sleeping.

I have seen a lot of interfaces that I would be fine describing as "jerking" due to async silliness. Largely from odd reflows that result when the code completes in an order that is not "top down" in the function.

It can be convenient to have the code "just wait" for an async spot, but I do think there are some benefits to forcing the a bit more structure around it.

Re: Multi-Core by Default

#50

Post by tom_ »

CJefferson wrote: post #7
bob1029 wrote: post #5

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…

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?

You're doing nothing wrong other than using async. You'll only become an async fan once you write a program that does no interesting CPU work, just a lot of I/O - because async is great for the case where the computer spends most of its time waiting around for multiple (or possibly even quite a lot more than that) I/O requests to complete, then does a bit of CPU work on completion of each in order to decide what I/O to do next. Then repeat forever.

This stuff is always a pain to do in languages that don't have this sort of facility, because you need to manually structure your code as some kind of state machine. But that's exactly the sort of tedious nonsense the computer can do for you, if only there's the language mechanism to let you explain to it what you want - which is exactly what async is for.

But it is fundamentally a cooperative multitasking mechanism, as code written in this manner expects to run atomically between awaits. So it's impossible for it to take advantage of multiple threads as-is, which is why languages supporting this mechanism don't bother.

If you are doing a lot of CPU work, that's a problem that async was never designed to solve. You need threads.

Post reply on HN