E
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
R
Rob Stow
Ed said:
No surprise there. One thing that has helped me
steer people to Opterons instead of Xeons is a simple
demonstration of the fact that a little 2 GHz Opty
dualie server might run for 40 minutes on the UPS
while a similarly configured 3.2 GHz Xeon dualie can
only run for 24 minutes off of the same UPS. If
the better server performance of the Opty doesn't
make idiotic Intel loyalists see the light, the UPS
times do.
When your business depends on being able to keep your
servers and workstations running during a power outage,
being able to place much smaller demands on your UPSes
and backup generators can make all the difference in the
world.
U
U. U.
No surprise there. One thing that has helped me
steer people to Opterons instead of Xeons is a simple
demonstration of the fact that a little 2 GHz Opty
dualie server might run for 40 minutes on the UPS
while a similarly configured 3.2 GHz Xeon dualie can
only run for 24 minutes off of the same UPS. If
the better server performance of the Opty doesn't
make idiotic Intel loyalists see the light, the UPS
times do.
When your business depends on being able to keep your
servers and workstations running during a power outage,
being able to place much smaller demands on your UPSes
and backup generators can make all the difference in the
world.
Is there any website that compares power and heat for all or most current
processors? I'll be using a slower speed than this article reports on.
Thanks.
J
JK
http://users.erols.com/chare/elec.htm
U. U. said:Is there any website that compares power and heat for all or most current
processors? I'll be using a slower speed than this article reports on.
Thanks.
J
Johannes H Andersen
Rob said:No surprise there. One thing that has helped me
steer people to Opterons instead of Xeons is a simple
demonstration of the fact that a little 2 GHz Opty
dualie server might run for 40 minutes on the UPS
while a similarly configured 3.2 GHz Xeon dualie can
only run for 24 minutes off of the same UPS. If
the better server performance of the Opty doesn't
make idiotic Intel loyalists see the light, the UPS
times do.
If this is really a problem, you could always use two UPS. This 'all
or nothing' attitude is idiotic. As I said before, once you're into
interesting projects and programming, the type of CPU you happen to
employ for the next few years is not uppermost on your mind, it's
what you can do with the system.
J
JK
Johannes said:If this is really a problem, you could always use two UPS. This 'all
or nothing' attitude is idiotic. As I said before, once you're into
interesting projects and programming, the type of CPU you happen to
employ for the next few years is not uppermost on your mind
Of course it is when you want to run 64 bit software. How many people
will be cursing in '05 because they bought a 32 bit processor in '04
instead of buying a 64 bit one? All 32 bit processors are old technology.
Imo anyone who pays more than $125 for a 32 bit processor is making
a very foolish choice.
J
Johannes H Andersen
JK said:Johannes H Andersen wrote:
{...]If this is really a problem, you could always use two UPS. This 'all
or nothing' attitude is idiotic. As I said before, once you're into
interesting projects and programming, the type of CPU you happen to
employ for the next few years is not uppermost on your mind
Of course it is when you want to run 64 bit software. How many people
will be cursing in '05 because they bought a 32 bit processor in '04
instead of buying a 64 bit one? All 32 bit processors are old technology.
Imo anyone who pays more than $125 for a 32 bit processor is making
a very foolish choice.
And all the 32 bit software will disappear tomorrow???
J
JK
Johannes said:JK said:Johannes H Andersen wrote:
{...]If
the better server performance of the Opty doesn't
make idiotic Intel loyalists see the light, the UPS
times do.
If this is really a problem, you could always use two UPS. This 'all
or nothing' attitude is idiotic. As I said before, once you're into
interesting projects and programming, the type of CPU you happen to
employ for the next few years is not uppermost on your mind
Of course it is when you want to run 64 bit software. How many people
will be cursing in '05 because they bought a 32 bit processor in '04
instead of buying a 64 bit one? All 32 bit processors are old technology.
Imo anyone who pays more than $125 for a 32 bit processor is making
a very foolish choice.
And all the 32 bit software will disappear tomorrow???
The Athlon 64 gives a person the choice of running 32 bit or 64 bit software.
They can also run both side by side with a 64 bit OS.
J
Johannes H Andersen
JK said:JK said:Johannes H Andersen wrote:
{...]
If
the better server performance of the Opty doesn't
make idiotic Intel loyalists see the light, the UPS
times do.
If this is really a problem, you could always use two UPS. This 'all
or nothing' attitude is idiotic. As I said before, once you're into
interesting projects and programming, the type of CPU you happen to
employ for the next few years is not uppermost on your mind
Of course it is when you want to run 64 bit software. How many people
will be cursing in '05 because they bought a 32 bit processor in '04
instead of buying a 64 bit one? All 32 bit processors are old technology.
Imo anyone who pays more than $125 for a 32 bit processor is making
a very foolish choice.
And all the 32 bit software will disappear tomorrow???
The Athlon 64 gives a person the choice of running 32 bit or 64 bit software.
They can also run both side by side with a 64 bit OS.
Have you tried it?
K
keith
JK wrote:
Johannes H Andersen wrote:
{...]
If
the better server performance of the Opty doesn't
make idiotic Intel loyalists see the light, the UPS
times do.
If this is really a problem, you could always use two UPS. This 'all
or nothing' attitude is idiotic. As I said before, once you're into
interesting projects and programming, the type of CPU you happen to
employ for the next few years is not uppermost on your mind
Of course it is when you want to run 64 bit software. How many people
will be cursing in '05 because they bought a 32 bit processor in '04
instead of buying a 64 bit one? All 32 bit processors are old technology.
Imo anyone who pays more than $125 for a 32 bit processor is making
a very foolish choice.
And all the 32 bit software will disappear tomorrow???
The Athlon 64 gives a person the choice of running 32 bit or 64 bit software.
They can also run both side by side with a 64 bit OS.
Have you tried it?
Certainly.
K
keith
Ah, a trip down memory lane, when "high power" was 15W. ;-)
Thanks!
J
Johannes H Andersen
keith said:Johannes H Andersen wrote:
JK wrote:
[...]
All 32 bit processors are old technology.
Imo anyone who pays more than $125 for a 32 bit processor is making
a very foolish choice.
And all the 32 bit software will disappear tomorrow???
The Athlon 64 gives a person the choice of running 32 bit or 64 bit software.
They can also run both side by side with a 64 bit OS.
Have you tried it?
Certainly.
Perhaps you could be a bit more specific: Which software, OS, Databases,
GIS, CAD, Compilers, COM, DCOM and network software did you try?
A
assaarpa
Perhaps you could be a bit more specific: Which software, OS, Databases,
What does that have to do with running side-by-side? The message was that
you won't be "losing out" on not being able to run existing 32 bit software
for 32 bit Windows. More important question to ask is not to start listing
thousands of software packages that work but to ask which packages you rely
on that doesn't and when will the upgrade be out in case it doesn't!
You have some specific examples of software that is known to malfunction on
Windows XP 64 bit edition!?
GIS, CAD, Compilers, COM, DCOM and network software did you try?
What does that have to do with running side-by-side? The message was that
you won't be "losing out" on not being able to run existing 32 bit software
for 32 bit Windows. More important question to ask is not to start listing
thousands of software packages that work but to ask which packages you rely
on that doesn't and when will the upgrade be out in case it doesn't!
You have some specific examples of software that is known to malfunction on
Windows XP 64 bit edition!?
J
Johannes H Andersen
assaarpa said:What does that have to do with running side-by-side? The message was that
you won't be "losing out" on not being able to run existing 32 bit software
for 32 bit Windows. More important question to ask is not to start listing
thousands of software packages that work but to ask which packages you rely
on that doesn't and when will the upgrade be out in case it doesn't!
But why should I submit to this upgrade tyranny when I didn't intend to run
Windows XP 64 in the first place?
You have some specific examples of software that is known to malfunction on
Windows XP 64 bit edition!?
Clean 32 bit software will probably run OK on Win XP 64. The problems will
come with mixed software and a mixture of dlls. E.g. you might have written
32 bit COM/.NET client extensions, these won't work if the target server
software becomes 64 bit.
Naturally, it will all settle down eventually, but it will take years, not
months. In the meantime I'll continue my work in 32 bits and produce useful
results.
A
assaarpa
But why should I submit to this upgrade tyranny when I didn't intend to
run
Well I didn't intend to get AIDS either but since I got it I mention it here
to steer the discussion to direction I want.
That's one point to the UNIX/POSIX crowd.. recompile & go.. no dependency on
specific hardware architechture for a lot of the time. A lot of Windows
software is indeed "hardcoded" for X86 and Microsoft proprietary API's. The
..NET Platform one way out of this situation, Microsoft tried to hijack Java
but failed miserably so they built their own toys for the job.
In the post-Longhorn era Windows development scenario if Billy's .Plan goes
as planned the software is JIT-style compiled On Demand by the .NET Platform
runtime/vm (CLR) so the "bitness" of client extensions is a moot issue
assuming the software is written using sound software development practises
such as Not Assuming Stuff (assuming platform is big or little endian,
having this or that width for registers and shit like that).
That's fine with everyone I'm sure but still 32 bit and 64 bit software runs
side-by-side on Windows XP 64 bit edition (as much as 64 bit software is
available, that is, which is very little / marginal at best) the case here
was that having the option to support both doesn't hurt even if for the time
being you want to produce useful results using tried and true tools.
Since we're going into "I think" terrotory instead of "just the facts", I
think that 64 bit Linux is much more mature platform for 64 bit software
development at this stage because of the general accessibility of the
development toolchain (namely the gcc). Plus ofcourse the environment is
superior for serious work, liau of "software you cannot live without"..
run
Windows XP 64 in the first place?
Well I didn't intend to get AIDS either but since I got it I mention it here
to steer the discussion to direction I want.
Clean 32 bit software will probably run OK on Win XP 64. The problems will
come with mixed software and a mixture of dlls. E.g. you might have written
32 bit COM/.NET client extensions, these won't work if the target server
software becomes 64 bit.
That's one point to the UNIX/POSIX crowd.. recompile & go.. no dependency on
specific hardware architechture for a lot of the time. A lot of Windows
software is indeed "hardcoded" for X86 and Microsoft proprietary API's. The
..NET Platform one way out of this situation, Microsoft tried to hijack Java
but failed miserably so they built their own toys for the job.
In the post-Longhorn era Windows development scenario if Billy's .Plan goes
as planned the software is JIT-style compiled On Demand by the .NET Platform
runtime/vm (CLR) so the "bitness" of client extensions is a moot issue
assuming the software is written using sound software development practises
such as Not Assuming Stuff (assuming platform is big or little endian,
having this or that width for registers and shit like that).
Naturally, it will all settle down eventually, but it will take years, not
months. In the meantime I'll continue my work in 32 bits and produce useful
results.
That's fine with everyone I'm sure but still 32 bit and 64 bit software runs
side-by-side on Windows XP 64 bit edition (as much as 64 bit software is
available, that is, which is very little / marginal at best) the case here
was that having the option to support both doesn't hurt even if for the time
being you want to produce useful results using tried and true tools.
Since we're going into "I think" terrotory instead of "just the facts", I
think that 64 bit Linux is much more mature platform for 64 bit software
development at this stage because of the general accessibility of the
development toolchain (namely the gcc). Plus ofcourse the environment is
superior for serious work, liau of "software you cannot live without"..
J
Johannes H Andersen
assaarpa said:Well I didn't intend to get AIDS either but since I got it I mention it here
to steer the discussion to direction I want.
That's one point to the UNIX/POSIX crowd.. recompile & go.. no dependency on
specific hardware architechture for a lot of the time. A lot of Windows
software is indeed "hardcoded" for X86 and Microsoft proprietary API's. The
.NET Platform one way out of this situation, Microsoft tried to hijack Java
but failed miserably so they built their own toys for the job.
There is no single best solution. What you find in organisations is a multitude
of different systems with years of investment in local development of business
logic and procedures. They all do a continuous job and can't just be re-written
or re-compiled (that easily). The .NET platform solves some problems but
introduces other. Also, you're not alone in the company, there may already be
a volume of 32 bit .NET development that needs to be checked for 64 bits.
..NET might work very well in areas of pure IT since there is a rich set of
components in the CLR, but I have some doubts for jobs that require numerical
analysis methods. But never mind, so we use native coding in those cases.
In the post-Longhorn era Windows development scenario if Billy's .Plan goes
as planned the software is JIT-style compiled On Demand by the .NET Platform
runtime/vm (CLR) so the "bitness" of client extensions is a moot issue
assuming the software is written using sound software development practises
such as Not Assuming Stuff (assuming platform is big or little endian,
having this or that width for registers and shit like that).
My favorite programmer expression: "It should work"...
That's fine with everyone I'm sure but still 32 bit and 64 bit software runs
side-by-side on Windows XP 64 bit edition (as much as 64 bit software is
available, that is, which is very little / marginal at best) the case here
was that having the option to support both doesn't hurt even if for the time
being you want to produce useful results using tried and true tools.
But I will see to that in due course. I don't expect that I 'need' to be
concerned about Windows XP 64 bit for the next couple of years. There are
simply too much else to think about.
Since we're going into "I think" terrotory instead of "just the facts", I
think that 64 bit Linux is much more mature platform for 64 bit software
development at this stage because of the general accessibility of the
development toolchain (namely the gcc). Plus ofcourse the environment is
superior for serious work, liau of "software you cannot live without"..
Sure; 64 bits is nothing new in fact. It is only new for the PC end of
the market. Linux is just one of many OS that you come across, again not
necessarily by choice, but as a facet of the world as is. The availability
of the source code is a strong point; I know of people who will only run
some OR (Operational Research) software if they can see the code so they
can be sure what it does.