3 ms·

Because most consumer software is not as insanely parallel as doing millions (billions?) of isolated lookups. If you ran most applications on the GPU, you'd se

by Groxx 14y ago

Because most consumer software is not as insanely parallel as doing millions (billions?) of isolated lookups. If you ran most applications on the GPU, you'd see something like a 1000x slowdown because you're only able to use a single path (instead of hundreds / thousands at a time), and each path is way way slower than your average CPU.

im3w1l 14y ago
>Because most consumer software is not as insanely parallel as doing millions (billions?) of isolated lookups. I think this is more due to tradition than due to necessity. But I have no hard data and sources for this.
- 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.

by Groxx 14y ago

im3w1l 14y ago

>Because most consumer software is not as insanely parallel as doing millions (billions?) of isolated lookups. I think this is more due to tradition than due to necessity. But I have no hard data and sources for this.

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.