Concurrency and Parallelism are worthless jargon
Some people write blog posts on the fine distinctions between the programming jargon of "concurrency" and "parallelism" as if this is very meaningful. But this is all dumb and stupid and inventing a problem out of thin air. What programmers really mean when they say "parallelism" is multicore hardware and what they really mean when they say "concurrency" is multiprocessing (which for nontechies means you can run two different computer programs or processes at the same time.)
Share on Facebook
- Instruction level parallelism is not the same as multicore hardware. Instruction level parallelism just means using multiple arithmetic-logic units at the same time. Which is really basically similar to running multiple cores at the same time. It's true that it isn't as flexible as what we usually think of as multicore hardware but the basic idea of improving performance rather than flexibility is the same. This applies to GPUs as well.
- Bit-level parallelism is not the same as multicore hardware. See carry lookahead adder. Bit-level parallelism generally uses multiple adders and I think the basic idea of having multiple units doing work at once is best given by the word multicore.
- My node.js server is concurrent but not multiprocessing. Your node.js server is using multiple processes but it just implements them via continuation passing style in order to simplify things, gain performance and reduce memory usage. It is true that there is a strong difference between multicore multiprocessing, preemptive multiprocessing and cooperative multiprocessing but they are all variants of the same basic idea.
- Multicore implies capabilities more than just speed gains. Instruction level parallelism isn't really the same as multicore because the ALUs can't do tasks fully independentally. This is just a matter of a degree of synchronization rather than a binary distinction. There is a huge degree of synchronization between separate cores on a chip such that using multiple cores on safety-critical software with very strict timing guarantees (hard-realtime software but I loathe the term) is a huge and open problem. There are no chips on the market today on which two processes can run completely independentally. Regardless, at that point you might just as well run two separate chips with separate memory modules or separate computers.