[Openmcl-devel] Octal-core Mac Pro
Lawrence E. Bakst
ml at iridescent.org
Mon Sep 18 08:45:14 UTC 2006
[This rambles off topic a bit]
Yep, octal desktops will be here soon. ULV (ultra low voltage) versions of Merom due next year, could allow for quad laptops and iMacs as well, albeit with slower cycle times and FSB speeds. If you had a choice of 2 x 2 GHz cores or 4 x 1 GHz cores, on a MacBook Pro, which would you order assuming the same price? I suspect must folks would order the machine with the faster cores.
Over the next 5-10 years the number of cores is headed towards 1024 or more. Actually a better metric than the number of cores is the number of simultaneously executing threads (SETs). Micro burst based Intel chips have Hyper Threading and the new Sun Niagara II chips will do 8 threads/core and they have 8 cores for 64 simultaneously executing threads. So today the number of SETs ranges from 2-64.
BTW, if you look at todays MPUs, the cores themselves don't take up the bulk of the space, the (L2) caches do. So it is easy to make room for more cores, they represent an ever decreasing percentage of die area.
I believe the rapid increase in the number of SETs is (very) under appreciated and will have a profound impact on all aspects of software design and implementation. If Lisp and its current runtime architectures are to survive this dramatic shift in the evolution of CPUs, Lisp will have to adapt.
The cycle time war is over, the thread (SET) war has begun.
Everyone should start thinking about what in means to write an application that can make use of say 128-256 simultaneously executing threads. If you were writing an editor like emacs today, it isn't enough to decide the best way to decompose the problem into objects and methods, but rather how to control (or maybe trigger is a better word) the execution of as many useful simultaneous methods as possible while synchronizing and coordinating everything. That's hard to do. The decomposition to classes and methods is mostly static, but threads can be dynamic as well. Also to be considered is how much thread creation and destruction happens. Thread creation could be all static or almost all dynamic. The paradigm bar must be raised or programmers are going to drown.
A fundamental change in the nature of programing is occurring; the programmer now has easy access to concurrently executing threads. What will we do with them and what help will we get from our favorite programming languages?
At 3:45 PM -0600 9/13/06, Hamilton Link wrote:
>Re: emails not that long ago on this list having to do with processors
>of choice, and the whole 32-bit vs. 64-bit thing:
>Openmcl-devel mailing list
>Openmcl-devel at clozure.com
More information about the Openmcl-devel