Re: Thinking about upgrading from dual PII

From: Chris (ithinkiam_at_gmail.com)
Date: 08/08/05 

Date: Mon, 08 Aug 2005 10:35:53 +0100

stefan patric wrote:
> On Fri, 05 Aug 2005 10:04:54 +0100, Chris wrote:
>
>
>>stefan patric wrote:
>>
>>>On Thu, 04 Aug 2005 14:13:04 -0700, SQ wrote:
>>>
>>>
>>>
>>>>I have a workstation I got in '99 with dual Pentiums II at 400Mhz and
>>>>128MB of RAM and 512MB of swap. It is all SCSI.
>>>>
>>>>I run Redhat 8 on it.
>>>>
>>>>It's pretty fast for my needs, but sometimes I can get a program to
>>>>swap, plus the motherboard is obsolete, and the fan is very loud and
>>>>noisy, and I don't need the huge full-size tower.
>>>>
>>>>I am thinking about upgrading to whatever is the latest and greatest CPU
>>>>with 512MB of RAM and 2GB of swap. Could someone quantify performance
>>>>increase I could expect? What is my choice of CPUs?
>>
>>[big snip]
>>
>>
>>>7. Wait on getting into 64-bit. Give it another year or so for it to
>>>be better supported. Not a lot of 64-bit apps out there, yet.
>>>
>>>
>>
>>I agree with all the above except for point 7. AMD64 has been supported in
>>Linux for nearly 2 years now and all the major distros (except perhaps for
>>Slackware) come with a 64-bit version. Apart from a few niggles (e.g.
>>wireless adapter drivers) everything runs well on 64-bit platforms.
>
>
> By "supported," I didn't mean the OS stuff. I meant native
> 64-bit applications.

So did I.

> There's no real speed advantage running a 32-bit app
> on a 64-bit system.

False.

> You need true 64-bit apps to take advantage of the
> 64-bit CPU. And from what I've been told by programmers, recompiling a
> 32-bit app with a 64-bit compiler gains little, if anything. It's still a
> 32-bit app. It may not even compile, or if it does, may not run.
>

Partly true. Just compiling the app for 64-bit doesn't mean it's
optimsed for the platform. However, it does mean it can take advantage
of larger memory and better floating point calculations, which on it's
own can give you very significant gains of up to 30%. See here for more:

http://www.linuxhardware.org/article.pl?sid=03/12/17/189239&mode=thread
http://www.linuxhardware.org/article.pl?sid=04/09/17/1453239&mode=thread
http://www.anandtech.com/linux/showdoc.aspx?i=2127&p=1

I think the programmers you were talking to didn't give you the full
picture (or were plain wrong).

All distros that support 64-bit will have everything available that
works in 64-bit mode, so it will very rarely be the case that you try
and load and run a package that doesn't work.

> So, you spend the extra money for 64-bit, but the only apps
> available are 32-bit. Money wasted. At least, until developers retool
> their code. That's why I advised the OP to wait a year before
> considering jumping into a 64-bit system. Also, in a year, prices will be
> down some.

How can it be money wasted when it's already there in the cpu? There is
*no* premium to pay for 64-bit! Just load a 64-bit distro and see the
difference for yourself at no extra cost.

Sure prices will be lower next year, but if that's your mentality you'll
never upgrade.

> As for me, someone who is looking to upgrade to a new or newer setup, I'm
> going to wait a year for 64-bit to mature a little more, before I decide,
> if 64-bit is for me. But for now, I'll just add 2 512MB sticks of RAM to
> my current system, and recompile the kernel. That should hold me until
> next summer. I hope.
>

That's you're choice, but don't give people wrong info just based on
your opinion.

Chris.

Relevant Pages

  • Re: A chip too far? Where is your solution Mr Larkin?
    ... Blowing in the wind, ... But wasting performance for reliablity though is never going to fly - not least because most times it would not have the desired effect. ... Hardware enforced memory protection for threads on a timesliced CPU can be made every bit as reliable as giving each one a physical CPU just a SMOP. ... hardware control over the things that programmers tend to screw up. ...
    (sci.electronics.design)
  • Re: OT Dual core CPUs versus faster single core CPUs?
    ... Then one core could be assigned to each application process ... The OS cpu will assign it a task, create its memory image, set up its ... "Most people fail to consider that good programmers are very ...
    (sci.electronics.design)
  • Re: a dozen cpus on a chip
    ... Multiple CPUs are hard to manage efficiently for general purpose ... All of which are easily done by timeslicing a single CPU. ... of executable files as my whimsy dictates. ... sloppy programming languages and sloppy programmers. ...
    (sci.electronics.design)
  • Re: why is there not a lisp pc?
    ... but I am still not convinced that this was the main reason. ... the number of programmers is itself endogenous: ... Since that time, better RISC chips have appeared, yet the 30 yo ... the "general purpose CPU niche"? ...
    (comp.lang.lisp)
  • Re: Multi-threaded app behaviour question
    ... Process A is also at priority 59 but not on a CPU. ... The programmers goofed and got the thread synchronisation wrong. ... Probably a timer in the process. ... Solaris does both multi-threading ...
    (comp.sys.sun.admin)