3 ms·

Of course it's far better to start several threads, throw all the instructions at the task scheduler, have it execute them in a random order, deal with synchron

Of course it's far better to start several threads, throw all the instructions at the task scheduler, have it execute them in a random order, deal with synchronization and concurrency issues. Of course that's better...

Jtsummers 10y ago
And I assume, then, that you're only ever using assembly for programming? Because that's the only way you can be sure you're not wasting any cycles.
Jtsummers 10y ago
A less snarky answer, leaving the other alone. You have a program that needs to run tasks A,B,C (can be in parallel) followed by D (must be sequential, after the others). You can optionally put everything in a serial process: ABCD But that's only "optimal" if you have a single core, and no asynchronous tasks (like a delay in B for accessing a file over the network, where it doesn't touch the CPU for 10 seconds). Or you can design it like: (A|B|C)D % where | indicates independence, parallelism Now, if we have a language like erlang or go, you can do something like (erlang is rusty): main() -> Pids = lists:map(fun (F) -> spawn(F, [self()]) end, [fun a/1, fun b/1, fun c/1]), lists:map(fun (Pid) -> receive Pid -> ok end end, Pids), d(). There, done. The scheduler, now, will handle the interleaving of each of those independent processes across the available cores. If you want to do that manually, without preemptive multitasking, have fun tuning it correctly. Do you have each parallel task look like this: TaskA: while(work-to-be-done) do-work yield And just hope for the best? Is the context switching really going to be worth it? You're running a yield on each iteration of the loop now. That's clearly wasteful as you lose out on things like branch prediction, cache speed versus RAM speed, for running over this a number of times. So now you have to tune each one of these if you really want the optimal results. And you have to know precisely what machine your target system is running. Yeah, in the embedded world, we've got that, and we pretty much do exactly what you suggest. Because we control the full stack. We know exactly what software runs on a CPU. We know exactly what the CPU speed will be. Memory access times. We can come up with near optimal, low-level coroutine style programs like this. But most programs don't run in such a known, quantified, and understood environment.

Jtsummers 10y ago

And I assume, then, that you're only ever using assembly for programming? Because that's the only way you can be sure you're not wasting any cycles.

Jtsummers 10y ago

A less snarky answer, leaving the other alone. You have a program that needs to run tasks A,B,C (can be in parallel) followed by D (must be sequential, after the others). You can optionally put everything in a serial process: ABCD But that's only "optimal" if you have a single core, and no asynchronous tasks (like a delay in B for accessing a file over the network, where it doesn't touch the CPU for 10 seconds). Or you can design it like: (A|B|C)D % where | indicates independence, parallelism Now, if we have a language like erlang or go, you can do something like (erlang is rusty): main() -> Pids = lists:map(fun (F) -> spawn(F, [self()]) end, [fun a/1, fun b/1, fun c/1]), lists:map(fun (Pid) -> receive Pid -> ok end end, Pids), d(). There, done. The scheduler, now, will handle the interleaving of each of those independent processes across the available cores. If you want to do that manually, without preemptive multitasking, have fun tuning it correctly. Do you have each parallel task look like this: TaskA: while(work-to-be-done) do-work yield And just hope for the best? Is the context switching really going to be worth it? You're running a yield on each iteration of the loop now. That's clearly wasteful as you lose out on things like branch prediction, cache speed versus RAM speed, for running over this a number of times. So now you have to tune each one of these if you really want the optimal results. And you have to know precisely what machine your target system is running. Yeah, in the embedded world, we've got that, and we pretty much do exactly what you suggest. Because we control the full stack. We know exactly what software runs on a CPU. We know exactly what the CPU speed will be. Memory access times. We can come up with near optimal, low-level coroutine style programs like this. But most programs don't run in such a known, quantified, and understood environment.