<div>I guess it is like getting a sports car, the things that make a sports car are the performance features. If you dont use them why did you pay the extra dollars? </div> <div> </div> <div>I guess if someone has information about Tweaking and tuning Linux for current technology let me know. </div> <div> </div> <div>I DO know that Intel's compilers are free for Linux. </div> <div> </div> <div>And yes the whole point (or at least one) is that I develop threaded server applications. just knowing that I can squeaze a bit more performace makes spending the extra money for a CPU makes since. Having the extra performance and not using it is a waste.</div> <div> </div> <div>David </div> <div><BR><BR><B><I>"Ingles, Raymond" <Raymond.Ingles@compuware.com></I></B> wrote:</div> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>> From: Aaron Kulkis<BR><BR>> But
fortunately, the Unix model (of which Linux is an implementation)<BR>> is fully able to grow with improved hardware with little notice for<BR>> the user... or even admins for that matter.<BR><BR>Well, yes. And Unix had the concept of multitasking and asynchronous<BR>operation from the get-go, which helps when moving to multiple CPUs.<BR><BR>However, it's not *quite* that simple. Taking good advantage of<BR>parallel processing takes conscious attention and design, at least on<BR>the application level. Some problems are easy to parallelize, but others<BR>are much harder. (The canonical example is trying to get a baby in one<BR>month using nine women...)<BR><BR>And some programs can 'get away with' un-thread-safe practices on a<BR>single-processor system, but can break badly when run on an SMP system.<BR>Effectively they don't bother 'protecting' sections of code from<BR>interference by other threads/processes/whatever. When there aren't any<BR>other processes running
at the same time, no biggie. But if they are<BR>run on a multiprocessing system, Bad Things can happen.<BR><BR>A few of the standard Unix and ANSI C functions essentially "assumed"<BR>one CPU in this manner. E.g. ctime(), getlogin(), the original concept of<BR>"errno", etc. See here:<BR><BR>http://www.unix.org/whitepapers/reentrant.html<BR><BR>That being said, the conversion to 'reentrant' code is essentially<BR>complete for Linux and has been for years. The same for the conversion<BR>to 64-bit processing (something Windows is still having trouble with).<BR><BR>Your point is basically correct, of course, but I figured a little<BR>expansion and clarification couldn't hurt. :-><BR><BR>Sincerely,<BR><BR>Ray Ingles (313) 227-2317<BR><BR>"It is as useless to argue with those who have renounced the use of<BR>reason as to administer medication to the dead." - Thomas Jefferson<BR><BR>The contents of this e-mail are intended for the named addressee only. It contains information
that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. <BR>_______________________________________________<BR>mdlug mailing list<BR>mdlug@mdlug.org<BR>http://mdlug.org/mailman/listinfo/mdlug<BR></BLOCKQUOTE><BR><p> 
<hr size=1>Ahhh...imagining that irresistible "new car" smell?<br> Check out
<a href="http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-">new cars at Yahoo! Autos.</a>