[Openmcl-devel] OpenMCL Versions

[Lawrence E. Bakst]

At 9:09 PM -0400 8/16/06, Andrew Shalit wrote:
>Larry --- great to hear from you, and see that you are on this list.  This all makes perfect sense, and reinforces what I think most of the rest of us have been feeling.
>
>If MCL was targeting Windows desktop applications, Intel 32 would be more important.  But I'm not hearing that from anyone, and looking forward the 64 bit architecture clearly is the way to go.  I also like your point about multiple cores.  I don't know whether Gary has put thought into that.  Gary?

[I had a long comment about OpenMCL's GC that I redacted.]

>
>You just left one thing out of your detailed analysis (aka crystal ball): the MacBook [not pro].  I'd assume you'd put that with the mini in the "may stay back for another round" category?

Sorry, I forgot about that platform. The ASP for the MacBook starts at $1099 and not $599 but of course the real question is what are the GM (gross margins) and those are closely guarded secrets. I suspect margins are a bit higher with the MacBook and therefore maybe the MacBook might get Merom before the Mini. However this is really pure (almost bogus) speculation. It's my hope that once Apple gets enough Merom chips they will just convert over wholesale. I still think that is possible before the end of the year if Intel doesn't have any hiccups. I suspect they want as small a 64bit Intel "gap" as possible.

While it is true that in some cases chips can drop in you may see Apple make motherboard changes to support say lower voltage versions of these chips. These changes will probably not be user noticeable.

I'd urge anyone getting a laptop to get a Pro model of they can find a way to afford the cost difference. It's a better and more rugged machine IMHO.

At 12:04 PM -0600 8/15/06, Gary Byers wrote:
>One of the things to bear in mind is that (unlike the PPC and Sparc
>and (AFAIK) MIPS architectures), x86 progams generally benefit from
>being compiled in 64-bit mode: 64-bit programs generally burn memory
>and cache lines faster, but (unlike their counterparts on saner
>architectures) 64-bit x86 programs have twice as many registers
>available to them.  C compilers like that at least as much as Lisp
>runtime systems do, and the Intel world has additional motivation
>for switching to 64 bits beyond the (still fairly esoteric) need
>to overcome address space limitations.

I believe micro-op fusion is turned off in EM64T mode. The jury is still out on how much of a hit that is. It's hard to benchmark it.

Best,

leb

>
>Andrew
>
>
>
>Lawrence E. Bakst wrote:
>>Hi Andrew,
>>
>>I don't think we have to wait a few weeks to guess at what the plans are. And hey, guessing is more fun than knowing. Of course I have no inside info at all, however there is a lot of information out there.
>>
>>All the new Intel Core-2 chips are 64 bit (EM64T). As most people know there are at least 3 versions of that architecture, Woodcrest, Conroe, and Merom, for servers, desktops, and mobile platforms respectively. Woodcrest and Conroe are announced. For now it looks like Apple will eschew Conroe, which I think is a good move. Over the long term with more and more unit volume in laptops and power challenged form factors such as the iMac, I wonder how long Intel will maintain a desktop version anyway. It's great that Apple has picked Woodcrest for the desktops as this is a very fast processor with a huge cache and lots of memory bandwidth, although the memory latency is an issue that no one want to talk about. Future chips could allow for an Octal version, which fun.
>>
>>I suspect that Merom will be announced soon. Intel is pulling everything forward. Once Apple can obtain sufficient volumes (the key issue) of Merom chips the MacBook Pro and iMac Apple will quickly switch over to that chip. It is mostly a drop in to the Napa architecture, although Apple will probably revise the motherboards. I wouldn't expect to see much change in the way of hardware features. That will wait for the Santa Rosa platform in 1H2007. At that time Merom chips will change from Socket M to Socket P.
>>
>>I think the big question is how long the Mac Mini will stay based on the 32 bit Yonah processors that don't have EM64T. This is much less clear as Apple needs a low price for this platform and that won't happen until there is a copious supply of Merom chips and in many cases the price won't be right until the second set of speed grades is announced so Intel can lower prices on the first set of speed grades. That's just how it works, although Apple may have a special deal (see below).
>>
>>Having said all that, with the possible exception of the Mac Mini I am almost 100% sure that all other shipping Macs will be EM64T by the end of the year. Who knows Apple may have a secret deal with Intel that allows them to be 100% 64 bit by the end of the year.
>>
>>I suspect that doing a x86 32 bit runtime is made much more difficult for Gary because you loose the 8 extra registers you gain with EM64T. Lispy runtimes really like their registers for storing a variety of information. Given the lineage of the MCL runtime, I think a port to X86 would be difficult, although I have some ideas on how to do it as I am sure Gary does.
>>
>>I have personally held off buying new Intel Macs for 2 reasons. No native  Photoshop yet and no EM64T processors needed for OpenMCL. Gary's a great coder but he's only a single person and when you have a small team you need to make tough tradeoffs.
>>
>>I personally think Gary should keep focused on the 64 bit EM64T version. There are already several runtimes to maintain and adding another just isn't worth the drag it will add to making forward. By the end of 2007 the percentage installed base 32 bit Intel systems will be a rapidly shrinking number.
>>
>>I'd rather see some of Gary's energy go into 2 areas:
>>
>>1. Getting a basic but very stable IDE up and running based on the pieces that already exist. I think that would be a huge boon for OpenMCL.
>>
>>2. Support for a very large number of cores. The number of cores is going to rise rapidly from 2 to 4 and then 8 and beyond.
>>
>>3. Some kind of debugger support in the IDE.
>>
>>For all those folks that bought early Intel systems and want to flame to me. Have at it.
>>
>>Best,
>>
>>leb
>>
>>
>>At 10:18 AM -0400 8/16/06, Andrew Shalit wrote:
>> 
>>>Thanks for all this feedback.  We should (knock on wood) know more about Apple's cpu plans in a few weeks.  Meanwhile, I'd second Hamilton's suggestion that anyone who knows they want to deploy on 32-bit Intel should let Gary know sooner rather than later.  It seems clear from feedback so far that 64 bit intel is higher priority.  Whether there's a 32-bit version would depend on demand and also resources/time available.
>>>
>>>Andrew
>>>
>>>
>>>Hamilton Link wrote:
>>>   
>>>>Raffael Cavallaro wrote:
>>>>
>>>>      
>>>>>It seems like supporting 32 bit intel is unavoidable unless you never distribute your software to other mac users.
>>>>>
>>>>>Raffael Cavallaro, Ph.D.
>>>>>
>>>>>
>>>>>  
>>>>>       
>>>>Supporting 32-bit intel is easily avoided by not porting to it ;).
>>>>
>>>>But seriously, the need to deploy their software on OSXintel32 seems
>>>>like it would be a compelling argument, if there was anyone who needed
>>>>to do this.  I was just responding to Andrew's question about platform
>>>>support based on my impression.  If anyone wishes to distribute
>>>>openmcl-derived software on intel32 they might want to make sure Gary
>>>>knows, because at the moment I don't think he's planning to support intel32,
>>>>
>>>>but it's easy enough for him to clear that up...  Gary, is that still
>>>>the case?
>>>>
>>>>h
>>>>
>>>>_______________________________________________
>>>>Openmcl-devel mailing list
>>>>Openmcl-devel at clozure.com
>>>>http://clozure.com/mailman/listinfo/openmcl-devel
>>>>      
>>>_______________________________________________
>>>Openmcl-devel mailing list
>>>Openmcl-devel at clozure.com
>>>http://clozure.com/mailman/listinfo/openmcl-devel
>>>   
>>
>>
>>