mdj wrote:
On Jun 19, 4:17 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:My own predictor for this unfortunate situation was media: once commodity hardware could manipulate AV data easily, the last application requiring more raw grunt passed us by ... It's not so much that you *can't* make a faster chip, but without the next big app to drive it, there's no compelling reason to invest the billions in the r&d required.Actually, it's still worth a lot to Intel (and AMD) to design and manufacture faster chips--the problem is that they don't know how to do it within the constraints of mainstream systems (eg, less than 100W of power dissipation by the processor). The fact is, if they can sell people on the idea that "more cores" is as good as "faster cores", then they can play the standard "memory-like" Moore's "Law" improvement, just replicating more cores on a single chip. (Of course, they need to share a lot of cache, so it's not "simple" replication, but the rules are pretty simple and well understood. Making faster cores, on the other hand, is not so simple. Most of the low-hanging fruit of single-thread parallel execution was harvested by the late 1990s, so there's not much left to do to speed up a single thread but increase the clock speed--and that has become increasingly difficult--especially given power limitations. As lithography is pushed to ever finer feature sizes, it has become necessary to do heroic things to work around metal lines becoming more like RC delay networks, and MOS gates from becoming quite leaky. There are still some small clock speedups, but they are certainly minor compared to the "doubling every year and a half" that the PC industry cut its teeth on. So it isn't so much that they don't think they would be plentifully rewarded for developing faster cores--it's that it has become a losing game, regardless of how much money you have to invest. BTW, chip fabricators--particularly Intel--continue to invest billions to build new fabs for the next smaller process "node"--it's just that newer processes enable *more* cores, not noticeably *faster* cores. And the cost of the "next generation" fab continues to grow exponentially-- just like Moore's "Law". ;-) Physical limits aside, it seems that we are approaching a point where the game may not be worth the candle. Tiny *low power* chips and circuits are, on the other hand, in great demand--mobile devices demand them.Which is as it should be I think... Transparent technology like for instance pens that record what you write, and what you heard as you wrote it - in sync :-)
I was quite impressed with the Leap Fly Fusion pen, but now I see that it has transformed into the Livescribe Pulse, and its price has gone up!
That said (and without wanting to play devils advocate), there are a few interesting data structures you can start playing with once things are 64 bit, for instance very large sparse hash tables. This is useful for "desktop search" applications like Apple's Spotlight or Google Desktop (and whatever the Microsoft equivalent is), which can use this to efficiently index and correlate all the information on your system. That's about the only legitimate use of a 64 bit address space I can think of on a desktop machine these days, but that said, Spotlight- like functionality is very handy, and you couldn't pay me to go back ...Actually, one of the possibilities of a 64-bit address space is that libraries (DLLs) can be statically linked to fixed addresses. The Apollo Domain OS took this approach in the early 1990s allowing some very advanced system concepts to be implemented rather simply.That's a good one. I suspect we'll see the consolidation of multiple applications into single address spaces as well. With many large apps today running on VM's, it gets obscenely wasteful to run multiple copies of said VM's holding multiple copies of bytecode and JIT output. The security models of the two most popular VM's today permit using the relatively cheap 'thread' context switch instead of a full 'process' switch. So there's a least some common areas where spending the overhead of 64 bits ends up saving more in the long run.
It is certainly possible to use a huge virtual address space to change the way things are done, reducing or eliminating overhead. But these types of changes are "against the grain" and are likely to be resisted.
Using the large address space to enable large, sparse tables will, of course, make every "hit" into a page fault...But a comparatively cheap hit, when compared to doing it further up the stack...
Well, the rule for fast databases was to make exactly one disk access for each lookup, so if the data object is located in the hash table, that works. ;-) There's always the problem that programmers must remember that a huge address space does not mean a huge physical memory. ;-) Programs must be designed around some expectation of a reasonable working set size. -michael ******** Note new website URL ******** NadaNet and AppleCrate II for Apple II parallel computing! Home page: http://home.comcast.net/~mjmahon/ "The wastebasket is our most important design tool--and it's seriously underused."