|
In short - yes their are very good reasons to be running 64 bit code particularly on heavily loaded, high performance and large scale web server systems - which we run. You made some very good points. The one thing that I think you overlooked is that 64 bit operating systems that are running on 64 bit processors are running 32 bit applications in a degraded mode - they are not native to the processor. The OS - which is operating in 64 bit mode has to switch back and forth between 32 and 64 bit modes since all system calls are ultimately being handled by 64 bit code. While Sun has seemingly made this a fairly minimal penalty on their SPARC systems - Intel certainly hasn't - 32 bit applications running on their 64 bit processors are paying a very high performance penalty. So far we have had very good results running a full 64 bit apache/php/mysql package on Solaris 10 under a very heavy, compute intensive load which is also taking advantage of caching php and having a large mysql memory partition. Is it faster than the same set of software compiled 32 bit? I don't know since we don't have the time and/or effort to try and setup an exact one-for-one test case. Is it performing well beyond expectations of what we were getting from our older Solaris 2.8 32 bit environment (running on the same ultrasparc hardware) - you bet and everyone is pleased. So while there may be some slight increase in code size - executables seem to have grown by an insignificant 4-5% in size. Memory use seems to be much more efficient and this is largely due to the fact that we have everything setup as DSOs - including the UW imap libc-client. The gains seem to well outweigh any penalties that you mention. Are we succumbing to 64 bit hype - maybe so - but I have also been around long enough in this business to have heard the same arguments as to whether there was much value in converting from 16 bit to 32 bit instruction sets. No matter what, computing is rapidly moving forward to a 64 bit world. Sooner or later requirements will occur that will mandate 64 bit applications. We would rather be there sooner rather than later. Customers are demanding ever more and they just don't want to hear about 2G file limits and other related issues. It is our job to find ways to satisfy their demanding requirements and in doing so we try to hedge our bets by keeping our technology moving forward in order to anticipate their needs. Will UW imap really benefit from being compiled 64 bit - probably not. Then again maybe it will open some doors to ideas that will be able to further improve performance - who knows. Our main problem is that unless we can build it 64 bit - everything else we have been doing 64 bit is for nothing and we will be held back to a 32 bit world. As for the problems in UW imap - I really think it is mainly an issue of trying to stuff 64 bits pointers into 32 bit integers. We have found this issue to be completely unique to UW imap. Even the far more complex asterisk PBX package compiles and operates cleanly in 64 bit. Mark Crispin wrote: I understand the issue about linking to a chain of applications, and this is the only reason why I'm even following this discussion instead of letting it drop. --
| ||||||
begin:vcard fn:Bob Atkins n:Atkins;Bob org:DigiLink, Inc. adr;dom:Suite 408;;4676 Admiralty Way;Marina Del Rey;CA;90292 email;internet:[EMAIL PROTECTED] title:President/CEO tel;work:310-577-9450 tel;fax:310-577-3360 url:http://www.DigiLink.Net version:2.1 end:vcard
_______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
