4 ms·
I doubt this is so. Lots of consumer software ends up being I/O bound, not CPU bound - even if they were completely rewritten to be crazy-parallel, you wouldn'
by Groxx 14y ago
I doubt this is so. Lots of consumer software ends up being I/O bound, not CPU bound - even if they were completely rewritten to be crazy-parallel, you wouldn't notice. Good portions of games could probably be parallelized significantly more than they are, but they're quite a bit different than most software, so that's not very indicative.
Then there's stuff like parsing data. Lots of times data is context-sensitive - that "<item>" could be a tag, or it could be wrapped in <![CDATA[ <item> ]]>. Without reading through it in order, you can only make certain assumptions. Some of this can be redone in a more parallel-friendly way, some of it is not so much - if it's encrypted or compressed, you're probably forced to pre-process it sequentially, or lose some of the quality of the security / compression.
For those (and think of how much crypto and compression there is in consumer stuff! Every SSL web endpoint, secure wifi connection, zipped file...), a powerful-core CPU or a custom piece of hardware (that only does a few algorithms) is your only option.
- im3w1l 14y ago>I doubt this is so. Lots of consumer software ends up being I/O bound, not CPU bound - even if they were completely rewritten to be crazy-parallel, you wouldn't notice. So for these programs it wouldn't matter either way. >Then there's stuff like parsing data How many states can you be in exactly? You can be in a CDATA, you can be in a quoted attribute, you can be in a tag, you can be between tags. Most other states are very local such as ampersand declarator ( &l ) , tagname started ( <it ), etc. You could process a text snippet for all of the more global possibilities at the same time (or just chance it and throw your guess out if you are wrong). I suppose you are right about compresssion and crypto.