|
|
|
|
|
|
| Author |
Message |
Bill Todd
*nix forums Guru
Joined: 24 Jul 2005
Posts: 408
|
 Posted: Fri Jul 21, 2006 4:17 am Post subject:
Re: New itaniums out at 2.5x perform gain
|
|
|
perfnerd@yahoo.com wrote:
| Quote: | Bill Todd wrote:
bob@instantwhip.com wrote:
http://www.informationweek.com/news/showArticle.jhtml?articleID=190500823
Ah, me - even an article that starts by bending over backward to try to
make Itanic look good has a lot of difficulty doing so these days - at
least if it doesn't play somewhat fast and loose with its wording.
Examples:
"Say this for Intel-after five years of [initially negligible and later
only] modest sales and [dramatically] scaled-down ambitions, it's not
[at least not yet] giving up on Itanium [at least not publicly]."
(bracketed clarifications added)
"The chips deliver more than twice the database performance of
previous-generation Itaniums [at the *chip* level, though only slightly
more *per-core* performance despite years of new development, 5x as much
L2 cache and 1.33x as much L3 cache, and significant core enhancements
like multi-threading: the rest comes from having two cores on the
chip], and draw 2.5 times less electric power [if you nimbly and
ever-so-tacitly switch the subject from the *chip* to *per-core* power:
the per-chip power is only moderately reduced]"
You are right, but it does really depend on whether you want to look at
the differences on a per core, per socket, per box, or per dollar
basis.
|
That was not the problem: the problem was that the article's wording
first referred explicitly to per-chip performance measurements and then
went on to state that power drain was down 2.5x *in the same context*
(when in fact it was down only 1.25x at the chip level).
That's called either linguistic incompetence or deliberate
misinformation, not mere difference of viewpoint.
| Quote: |
Montecito does draw less per socket than Mad9M.
|
As I noted above.
The Mad9M is rated at
| Quote: | 130Watts, while the Montecito is rated at 104Watts. That is 26% less
wattage on a per socket basis.
|
That is in fact 20% less wattage on a per-socket basis the way I learned
arithmetic.
Which is significant if you are buying
| Quote: | based on a core count, since the same number of CPUs draw 40% the
power.
|
Absolutely: you can either get similar performance at less than half
the power, or over twice the performance at about the same power. But
you cannot (as the article's wording suggested) get over twice the
performance at less than half the power.
The bottom line is that the only really impressive achievement in
Montecito is its power reduction for a given level of performance:
doubling up the cores as a result of the process shrink is certainly
useful, but relatively straight-forward by comparison.
| Quote: |
At the box level, the new Montecito SuperDome is shown on the SPEC site
as being able to achieve a SPECint_rate2000 base of 2367 with 128 CPUs
/ 64 sockets (Jul 2006), vs 1108 for the 64/64 for the Mad9M Superdome
(Jan 2005)
|
Hmmm. Assuming that the results scale pretty linearly (which they seem
to these days for SPECint_rate), that's not that much of a boost per
core over Mad9M considering Montecito's L2 and L3 cache improvements,
the significantly reduced memory latency that the sx2000 chipset
supposedly provides (the 533 MHz bus speed does imply that the sx2000 is
being used, does it not?), and whatever compiler improvements occurred.
| Quote: | and 1063 for the 64/32 IBM P5 595 (Oct 2004).
|
One might suspect that the POWER5+ when IBM sees fit to submit a
large-system configuration will enjoy a modest per-core advantage over
Montecito, given the minimal per-core advantage that Montecito and
sx2000 appear to enjoy over Mad9M and sx1000. Perhaps zx2 will uphold
Itanic's small-system honor in SPECint.
- bill |
|
| Back to top |
|
 |
Neil Rieck
*nix forums Guru Wannabe
Joined: 13 May 2005
Posts: 274
|
| Posted: Fri Jul 21, 2006 10:52 am Post subject:
Re: New itaniums out at 2.5x perform gain
|
|
|
"JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message
news:44C02E7F.418AFACE@teksavvy.com...
| Quote: | Bill Gunshannon wrote:
[...snip....]
Remember that the 8086 has gone from a 16 bit toy controller with 640k
memory limit and segment registers into a 32 bit CPU with full features
and now 64 bit machine. In the process, it has gained many more
features. So while the 8086 circa 1990 was definitely ill suited to run
VMS, the CPUs made today for that architecture have gained respectability.
|
Despite what Intel + AMD marketing folks would have us believe, these
product lines you are referring to are not 64-bit. It may seem so, to some,
because CPU and "memory management" functions have been integrated (read
blurred) but these CPUs are only 32 bits wide.
To understand this better, think about the PDP-11 system which was a 16 bit
CPU. The memory management system allowed the CPU to address memory using
18-bit, 22-bit, and 24-bit access. This worked by having the CPU first
initialize MMU registers which were later combined (added) with 16-bit
addresses coming from the CPU to generate a wider address going to memory.
But there was "no way" any single process could "see" more than 16-bits of
memory at a time without first asking the OS to manipulate the associated
memory management registers.
p.s. I remember the same thing with VAX. Memory management registers would
allow the CPU of some larger machines to access 40-bit (and 46-bit ?)
memory.
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/links/cool_openvms.html
http://www3.sympatico.ca/n.rieck/links/openvms_demos.html |
|
| Back to top |
|
|
Bill Gunshannon
*nix forums Guru
Joined: 21 Jul 2005
Posts: 1019
|
| Posted: Fri Jul 21, 2006 11:49 am Post subject:
Re: New itaniums out at 2.5x perform gain
|
|
|
In article <44C02E7F.418AFACE@teksavvy.com>,
JF Mezei <jfmezei.spamnot@teksavvy.com> writes:
| Quote: | Bill Gunshannon wrote:
Maybe so, but after years of hearing how the x86 architecture was
unsuitable for running VMS it seems highly unlikely that the addition
of 64 bit extensions has somehow corrected all those shortcomings.
Remember that the 8086 has gone from a 16 bit toy controller with 640k
memory limit and segment registers into a 32 bit CPU with full features
and now 64 bit machine. In the process, it has gained many more
features. So while the 8086 circa 1990 was definitely ill suited to run
VMS, the CPUs made today for that architecture have gained respectability.
|
We aren't talking about 1990. It was as recently as 2004-2005 that
we were once again reminded that the x86 architecture was deficient
and unsuitable for VMS. They weren't talking about your beloved
8086 (which has been dead for decades!) they were talking about
current x86 architecture. Again, I am not saying it can't be done,
only that if you were waiting for VMS Engineering to "look" at it,
they have and repeatedly said it didn't meet their requirements.
| Quote: |
Not saying it can't be done, just that the idea that porting VMS
to IA64 somehow made it easier to port to x86 is quite a stretch.
Posting to IA64 specifically gave VMS the ability to do EFI. That meant
tweaking the file system to allow a FAT partition-in-a-VMS-file with
updates to BACKUP, INIT etc to support this.
|
EFI, FAT, etc. are not the CPU. It was the CPU they said were deficient,
not systems designed around it which could certainly have been changed.
| Quote: |
But the port just made, no matter what the target was, game VMS the
ability to have a common code base supporting multiple architectures at
the same time,
|
Common code base between two architectures. Alpha and IA64. What
good did that do for the VAX? If these changes don't help an already
existing architecture what possible effect could they have on an as
yet none existant architecture? And, if as they have stated in the
past, the x86 architecture is deficient how can a common code base
cure the hardware problems?
| Quote: | and this allowed engineers to continue to work on VMS
while the port was being done. And a lot fo stuff was cleaned up and as
someone else said, many hardware features were moved to software, thus
making VMS less dependant on hardware.
|
But the CPU has been declared deficient. All the software in the world
can't fix that.
| Quote: |
So the next port will be easier.
|
Yeah, the Linux guys thought that too. Have you seen VAX Linux lately?
| Quote: |
True, but JF has always had this pipe dream that a bunch of engineers
are kept chained up in the basement of ZKO working 24/7 on some
mystery x86 port.
I never said they were chained  :-)
Many people from HP (in a better position to know than
JF) have repeatedly stated there are no plans, at this time, to do an
x86 port.
Yes, and that is perfectly normal. Until the second when HP/Intel
announce the end of IA64, expect everyone within HP/Intel to deny any
plans to abandon IA64. Announcing plans to port VMS to the 8086 would be
tantamount to announcing the end of IA64.
|
"Two people can keep a secret. If one of them is dead."
| Quote: |
And while I may be hoping for a Covert port of VMS to the 8086 going on
right now, (the faster, the better), I think it would be realistic to
think that someone within VMS engineering has looked into the
feasability of porting VMS to a 64 bit 8086 based on EFI and reported
back to very high management
|
If they reported to management the same thing they reported here,
well, you should get the picture...
| Quote: | and kept this very discreet.
|
"Two people can keep a secret. If one of them is dead."
| Quote: |
Note that this had happened prior to the announcement of the prematire
euthanasia of Alpha. I think it was 2 engineers that were tasked to
secretely make a feasability study of porting VMS to IA64. The rest of
the engineers were totally oblivbious to those plans.
When (and if) such a port is to be attempted it will likely get the same
fanfare as all the other ports. It is not the kind of thing that can be
kept hidden away, even if there was some business reason for doing so.
Once it is announced, you are right. But until that time, it is quite
possible to see VMS engineers talk to Intel engineers about what
features they may want in the generation of chips that would come circa
2007.
|
And exactly why would Intel give a rat's patootie? If it ain't needed
to run Windows, it is not sound business practice. If VMS is to run on
x86 and survive, it has to run on the same x86 exeryone else is running
on. If it is going to require modification of the CPU, it is dead.
| Quote: | Also, someone would also be talking about the types of features
that would allow one to build an 8086 based Wildfire/Galaxy class machine.
|
Why? Didn't we just hear that Galaxy is dead?
| Quote: |
Again, I have to defer to the HP people who are in a better position
to know and they have repeatedly stated here that the resources no
longer exist at HP to revive the Alpha line.
Horse manure. Where there is a will, there is a way.
|
Only up to a point. These are businesses. All the will in the world
won't change business realities. I used to own a 1979 Triumph Spitfire.
There is a company in England that bought the factory where they used
to be made at the bankruptcy auction. They now manufacture all the
parts themselves. So, why don't they just manufacture and sell the car
again to meet the demand of enthusiasts? A breand new Triumph Spitfire
made from their parts would cost over $100,000. There are people with
the will and this company provides a way. Still doesn't make it practical.
| Quote: | But there is
clearly no will at HP to revive Alpha, no will to even postpone the end
of sales date. And if the will existed, it would take a lot of creative
accounting to cost justify restarting Alpha with a huge amount of
resources to catch up.
|
So you basicly just supported what I said in the first place, Alpha is
a dead issue.
People need to go back and remember what Carly said. "We have burned
our boats." What does that mean for VMS? It means that HP put all its
eggs in the IA64 basket and did it very deliberately. They did all they
could to make sure there was no way to turn back. If that bodes badly
for people here, there really isn't a lot to be done about it. Unless
you know a real good boat-builder here in the brave new world.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h> |
|
| Back to top |
|
|
Bill Todd
*nix forums Guru
Joined: 24 Jul 2005
Posts: 408
|
| Posted: Fri Jul 21, 2006 12:17 pm Post subject:
Re: New itaniums out at 2.5x perform gain
|
|
|
Neil Rieck wrote:
| Quote: | "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message
news:44C02E7F.418AFACE@teksavvy.com...
Bill Gunshannon wrote:
[...snip....]
Remember that the 8086 has gone from a 16 bit toy controller with 640k
memory limit and segment registers into a 32 bit CPU with full features
and now 64 bit machine. In the process, it has gained many more
features. So while the 8086 circa 1990 was definitely ill suited to run
VMS, the CPUs made today for that architecture have gained respectability.
Despite what Intel + AMD marketing folks would have us believe, these
product lines you are referring to are not 64-bit. It may seem so, to some,
because CPU and "memory management" functions have been integrated (read
blurred) but these CPUs are only 32 bits wide.
To understand this better, think about the PDP-11 system which was a 16 bit
CPU. The memory management system allowed the CPU to address memory using
18-bit, 22-bit, and 24-bit access. This worked by having the CPU first
initialize MMU registers which were later combined (added) with 16-bit
addresses coming from the CPU to generate a wider address going to memory.
But there was "no way" any single process could "see" more than 16-bits of
memory at a time without first asking the OS to manipulate the associated
memory management registers.
|
The above is complete and utter horseshit. The most charitable
explanation I can come up with is that you're confusing the 32-bit
'programmable address extension' (PAE) mechanisms - which have existed
for a decade or so and which indeed resemble the PDP-11 memory-mapping
facilities you refer to in that they allow an IA32 process to use more
than 4 GB of physical RAM but not to see any more than 4 GB at any one
time - with the new x86-64 extensions which beyond question *do* make
x86-64 every bit as much a 64-bit architecture as the earlier x86s were
32-bit architectures. In x86-64 the registers are 64-bits wide, the
internal data paths are 64-bits wide (the first Intel variant used a
double-pumped 32-bit ALU to perform 64-bit operations, but this was as
much an optimization - in that it allowed narrower operations to execute
at twice the CPU speed - as a band-aid), and programs have access to a
flat 64-bit virtual address space without requiring any memory-mapping
assistance from software.
- bill |
|
| Back to top |
|
|
Dan Foster
*nix forums Guru
Joined: 29 Mar 2005
Posts: 593
|
| Posted: Fri Jul 21, 2006 1:06 pm Post subject:
Re: New itaniums out at 2.5x perform gain
|
|
|
In article <44c0b117$0$4147$9a6e19ea@news.newshosting.com>, Neil Rieck <n.rieck@sympatico.ca> wrote:
| Quote: | and now 64 bit machine. In the process, it has gained many more
features. So while the 8086 circa 1990 was definitely ill suited to run
VMS, the CPUs made today for that architecture have gained respectability.
Despite what Intel + AMD marketing folks would have us believe, these
product lines you are referring to are not 64-bit. It may seem so, to some,
because CPU and "memory management" functions have been integrated (read
blurred) but these CPUs are only 32 bits wide.
|
Er... no, the latest 64-bit processors in that family _are_ true 64 bit
processors. I'll explain in a moment, if you'll bear with me, please. :)
| Quote: | To understand this better, think about the PDP-11 system which was a 16 bit
CPU. The memory management system allowed the CPU to address memory using
18-bit, 22-bit, and 24-bit access. This worked by having the CPU first
initialize MMU registers which were later combined (added) with 16-bit
addresses coming from the CPU to generate a wider address going to memory.
But there was "no way" any single process could "see" more than 16-bits of
memory at a time without first asking the OS to manipulate the associated
memory management registers.
|
Right: the PDP-11 had a 16-bit data bus and 16 to 22 bit address bus
depending on what memory access scheme was being used.
The data bus width is why the PDP-11 is considered to be a 16 bit
processor.
Same deal with the 65816 which was used in the Apple IIGS and Super
Nintendo systems: 16-bit data bus, 24-bit address bus, considered to be
a 16-bit processor.
However, the EM64T and AMD64 processors *are* full 64 bit internally.
They are at least 64 bits wide for the _data_ bus (as well as for the
various registers including all of the GPRs), which is the big thing.
All pointers are 64-bit. All pushes and pops for the stack is 64-bit.
(The operands are 32-bit wide, but then again, do they really need more
than ~4.2 billion defined operands?)
Accessing data in the registers and memory is not a matter of internally
stringing up two adjacent 32-bit registers or 32-bit memory addresses.
(First version of this stuff may have done that, but current versions
don't. It's a full and true 64-bit access.)
The address bus is not quite 64-bit wide in current implementations, but
likely eventually will either reach 64-bit or come closer to it --
today's implementations are still much wider than terrible 32-bit hacks
like PAE to squeeze an extra 4 bits out of addressing.
On AMD64 64-bit processors, 32-bit is available as a _compatibility mode_.
I'm not sure if it's considered to be a compat mode on EM64T.
For more detailed information about these two architectures:
http://en.wikipedia.org/wiki/AMD64
http://en.wikipedia.org/wiki/EM64T
(The EM64T page is rather sparse, admittedly. AMD64 page is pretty good.)
One of the big things distinguishing EM64T and AMD64 from other
traditional 64-bit implementations such as Alpha, UltraSPARC, POWER3
(and later), Itanium, etc. is that EM64T/AMD64 has *much* fewer GPRs due
to their precedessors originally being a CISC design.
Cheers,
-Dan |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 9:13 pm | All times are GMT
|
|
WoW Gold | MPAA | Mortgages | Personal Loans | Internet Advertising
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
