128bit vs 32bit
dave
Can somebody please explain why a 128bit cpu is more powerful
then a 32bit? In a theoretical example would a 100Mhz 32bit cpu
be 4 times slower then a 100Mhz 128bit, if the architectures
were identical? Is it simply the fact that the cpu can work
with 128bit at a time that makes it 4 times faster?
Thanks, Dave
Jeffrey S. Dutky
Simply put, a "128-bit CPU" is only "more powerful" than a
"32-bit CPU" in that operations on 128-bit values can be
performed more rapidly on the 128-bit device than on the
32-bit device (all other things being equal). For most tasks,
however, I would assume that a 128-bit device would be no
different in performance from a similarly clocked 32-bit
device. In fact, I might expect that a 128-bit device would
be harder to clock at the same speed as a 32-bit device, due
to the larger number of bus lines involved in the wide
architecture. (It would appear, in fact, that my assumption
is borne out by the Itanium debacle, which is failing to live
up to promised clock speeds, while the narrower IA-32 devices
are well on their way to multiple GHz).
If the narrower architecture, however, implements some special
features that can handle wide operands (such as are found in
Intel's SSE or Motorola's Altivec) I would expect that there
would be no advantage what-so-ever in the wider architecture
over the narrower one, in terms of raw computational performance.
The big advantage if wider architectures has, for the most part,
not been one of performance, but of larger addressable memories.
This was true for the shift from 16->24->31 bit in the IBM
System 360, and with the PDP-11->VAX->Alpha shift for DEC, as
well as several others. While performance did increase across
the architecture shifts, there is no reason to believe that
the same raw performance could not have been achieved with the
narrower architectures in the more modern processes, but the
higher performance would have been hobbled by an inability to
address useful amounts of memory.
We should also not overlook the fact that, at least in the
desktop microcomputer world, much of the talk of 'bitness' has
been little more than a marketing ploy, with not much in the
way of technical facts to back it up.
- Jeff Dutky
Dennis O'Connor
> Can somebody please explain why a 128bit cpu is more powerful
> then a 32bit?
No, because as stated, the premise is false.
--
Dennis O'Connor dm...@primenet.com
Vanity Web Page: http://www.primenet.com/~dmoc/
Anthony Hill
>Can somebody please explain why a 128bit cpu is more powerful
>then a 32bit?
Is a "It's not" a good enough answer?
> In a theoretical example would a 100Mhz 32bit cpu
>be 4 times slower then a 100Mhz 128bit, if the architectures
>were identical? Is it simply the fact that the cpu can work
>with 128bit at a time that makes it 4 times faster?
Nope, the 128bit CPU would probably actually be slower. The more bits
of the CPU just mean that it can deal with larger numbers and can
address more memory (well, actually the exact definition of what
constitutes a "32bit CPU" vs. a "64bit CPU" is somewhat of a debate in
itself). It does not mean that it will be in any way faster, except
in those cases where you need to address more then 4GB of memory or
where you commonly need fixed point numbers that are greater then 4
billion in size, ie not too often unless you've got a real big server.
Also, since with a 128-bit chip you now need to fetch 128-bits from
memory for each piece of data instead of only 32-bits, you're
performance actually suffers.
So, that begs the question, why all the fuss about 64-bit and 128-bit
processors. Well, first off, you won't see a single general purpose
128-bit processor out there simply because they hurt your performance
without offering any advantages over 64-bit chips. When comparing
64-bit chips vs. 32-bit chips, well now you get into the two
advantages mentioned above, err... well at least the larger
addressable memory area is an advantage here. For a fairly high-end
server these days, 1 or 2GB of memory would be about the minimum, and
2-4GB is not at all uncommon with >4GB being used quite often on the
highest end servers. Even some workstations are starting to push
towards 4GB of more. With a 32-bit chip, this wouldn't normally be
possible, unless you do a little bit of trickery like Intel and AMD do
with their processors (using a 36-bit address bus on their 32-bit
processor). Still, a true 64-bit processor is really a good idea
here.
Now, the other time that you see 128-bit "processors" is in the
graphics world (video cards, game consoles, etc.), where the extra
bits are used for quite different functions. Here, the data is
graphics textures rather then numbers, and they often are much
different. These chips deal with data and memory in much larger
pieces then your typical general purpose CPU does, so for them the
fatter pipes of these processors is a very big advantage.
So, for a straight processor, 128-bits doesn't make much sense at all
(64-bits gives you a HUGE addressable memory range), but for pushing
graphics the ability to deal with data in larger chunks makes sense.
In gaming consoles 128-bit processors are the norm because their main
task is dealing with graphics while the actual computational stuff
(the AI, user interface and holding everything together) is more or
less secondary. For PCs, your graphics card does all the graphics
pushing, which is why they're mostly 128-bit chips, while your PC
actually works better as a 32-bit chip.
----
Anthony Hill
hi...@uoguelph.ca
Torben AEgidius Mogensen
For some tasks (specifically tasks that require calculation with large
integers, such as cryptography), a 128-bit CPU may be close to four
times faster than a 32-bit CPU. For other tasks it may be no faster at
all. Typically, the number of bits in registers/ALU has little impact
on the speed of memory transfers - here the width of the external but
has more to say.
If the CPU supports operations where a 128-bit register is treated as
4 32-bit numbers such that you can add 4 pairs of 32-bit numbers as
fast as a single pair of 128-bit numbers, other tasks may benefit as
well. Such operations are typically called vector-operations and are
often used for graphics or signal processing.
Torben Mogensen (tor...@diku.dk)
Paul DeMone
"Jeffrey S. Dutky" wrote:
[...]
> be harder to clock at the same speed as a 32-bit device, due
> to the larger number of bus lines involved in the wide
> architecture.
Bus width has little to with it. Where word length can impact
clock rate is in propagating functional units such as adders
and barrel shifters. Often superpipelining the unit can prevent
it from limiting the clock rate. Other functionals that don't
propagate fully, like SIMD units aren't affected (I once worked
on a graphics chip that was effectively 4096 bits wide but
ran happily at 66 MHz in 0.5 um).
> (It would appear, in fact, that my assumption
> is borne out by the Itanium debacle, which is failing to live
> up to promised clock speeds, while the narrower IA-32 devices
> are well on their way to multiple GHz).
Unless it was completely and utterly botched, the 64 bitness of
Merced has no material effect on its clock rate compared to all
its other problems. If Intel can get half cycle latency 32 bit
adders to operate up to 2 GHz in 0.18 um then it is obvious one
cycle 64 bit adders would not limit an 800 MHz MPU. BTW, the 64
bit McKinley will reportedly run at 1.2 GHz in the same process.
>
> If the narrower architecture, however, implements some special
> features that can handle wide operands (such as are found in
> Intel's SSE or Motorola's Altivec) I would expect that there
> would be no advantage what-so-ever in the wider architecture
> over the narrower one, in terms of raw computational performance.
Speaking of Motorola and Altivec, what does your hypothesis
relating word length to clock rate say about the 32 bit G4's
inability to clock faster than Merced let alone at "multiple
GHz"?
> We should also not overlook the fact that, at least in the
> desktop microcomputer world, much of the talk of 'bitness' has
> been little more than a marketing ploy, with not much in the
> way of technical facts to back it up.
This problem is long gone, at least for MPUs. There were a few
instances of the Pentium being marketed as a 64 bit processor
because of its data bus width but the growth in real 64 bit MPUs
seemed to head off this type of nonsense before it could spread
like in the days of 8 vs 16 and 16 vs 32 bit MPUs.
--
Paul W. DeMone The 801 experiment SPARCed an ARMs race of EPIC
Kanata, Ontario proportions to put more PRECISION and POWER into
dem...@mosaid.com architectures with MIPSed results but ALPHA's well
pde...@igs.net that ends well.
John R. Mashey
historically, when people called a CPU "N-bits",
the "N" normally meant the width the regular integer registers,
NOT the width of floating-point or other special registers
NOT the width of external busses
NOT the width of other special datapaths
NOT the size of instructions
Occasionally, as in the Intel i860 (where a 32-bit CPU with a 64-bit bus
was labeled a 64-bit CPU), or in games/graphics devices labeled as 128-bit
devices (that normally incorporate 32- or 64-bit CPUs using the historical
definitions), marketing gets the upper hand, at which point some people
declare that the terminology is confused. As far as I can tell, people who
actually design CPUs rarely are confused about "bittedness", and marketing
diversions have been relatively rare.
2) Using the normal definition, there are lots of 32- and 64-bit CPUs;
I can't think of a real 128-bit CPU, and there are certainly aren't any
widely-used 128-bit micros. Moore's Law wouldn't predict a need for 128-bit
(for addressing) until ~2040, and it cannot persist that long, although
perhaps some non-CMOS technologies might.
[Rationale: we started *needing* 64-bit micros for addressing around 1995,
when we added 32 bits to the existing 32-bits so people could straightfordwardly
get near/above 4GB. Moore's Law consumes 2 bits every 3 years.
32 bits / (2 bits/3 years) = 48 years. 1995+48 => ~2040.
3) It always costs more die space for wider datapaths, and it may cost cycle
time, or cycle-count, if one implements wider paths than people actually
need, and hence people don't do this until there are compelling reasons.
At the moment, I can't think of a widely-compelling reason to have widespread
use of 128-bitters before 2040, except possibly some kinds of encryption calculations, although of course some mathematicians would be quite pleased to have fast 128-bit integer multiplies and divides.
Attached below is the usual historical post:
=============================Article: 27876 of comp.std.c
Date: Mon, 22 Dec 97 17:35:48 1997
In article <66ig6f$7...@news.inforamp.net>, pcu...@acm.gov (Peter Curran) writes:
|> >The "bitness" of a CPU isn't a well-defined term but it most often
|> >refers to the width of data registers used for common integer based ops.
Yes, (not well-defined, but usually width of integer data registers);
this has been discussed *many* times in comp.arch, and elsewhere,
such "64-bit Computing" BYTE, September 1991 135-142, whose Table 1 lists
relevant characteristics of 20 CPUs, which I show later
|> >Machine addresses often have the same width but don't always do so and
|> >C pointers are something else again (you just have to take a look at DOS
|> >memory models).
|>
|> Agreed that "bitness" is not well defined (in fact, all but meaningless) but
|> this is a definition I have never heard before. The most common definitions
|> have heard refer to the number of bits transferred in parallel between the
|> processor and memory (a vague concept), and the number of bits in the machine's
|> physical addresses.
It might be wise to stop listening to the people from which these have
been heard... as they appear to know little of common usage in
computer architecture. The above is an assertion that the "N" in N-bit
computers means "A" or "D" bits below:
From the BYTE article above:
"Table 1 lists numbers for well-known computer families. For simplicity,
V (Virtual address size) is given only for user-level programs. The table
shows that physical address size (A) and data bus size (D) can vary within a
processor family. The IBM S/360 fmaily included five data bus sizes
(8 to 128 bits); the 32-bit Intel 386 is sold in 2 sizes -- 32 and 16."
Table 1: The size that a microprocessor is called is generally the integer
register size.
Size ---ISA------ ---Implementation---
Virtadd Physadd Databus
CPU Year Called Reg V A D
DEC PDP 11-45 1973 16 16 16* 18 32
DEC PDP 11-70 1976 16 16 16* 22 32
DEC VAX 11/780 1978 32 32 31 32 64
IBM S/360 1964 32 32 24 24 8,16,32,64,128
IBM S/370XA 1983 32 32 31 32 128
IBM ESA/370 1988 32 32 31* 32 128
IBM RS/6000 1990 32 32 32* 32 64-128
HP PA 1986 32 32 32* 32 32-64
Intel 386DX 1985 32 32 32* 32 32
Intel 386SX 1987 32 32 32* 24 16
Intel i860 1989 64 (!) 32 32* 32 64
MIPS R2000 1986 32 32 31 32 32
MIPS R4000 1990 64 64 40-62 36 64
MIPS R4300i 1995 64 64 ?? ?? 32 (added)
Motorola 68000 1980 (below) 32 24 24 16
Motorola 68020,030,040 1985+ 32 32 32 32 32
Sun SPARC 1987 32 32 32 36 32-64
* These processors use some form of segmentation to provide more bits of user
address space when necessary."
This list included most of the widely-used microprocessors used/public at
the time, plus the most popular mainframe and minis. Alpha, and later
64-bit SPARCs would have entries similar to R4000s.
1) When people call a processor an N-bit processor, it most often means the
architectural (ISA) size of the integer registers (R), and has meant this
for at least 35 years (since the world didn't start with S/360s).
2) Likewise, for many years, there have been multiple implementations of
the same architecture whose physical address sizes (A) and bus widths (D)
have varied widely relative to R, although bus widths are at least usually
integer multiples or divisors of R. About the only consistency is that
D is an integer multiple of R, or vice-versa, whereas A can be smaller than,
equal, or greater than R, and there need be no multiplier/divisor ratio.
3) The Intel i860 was called a 64-bit processor because it had a 64-bit
bus. In my opinion, this was simply marketing contrary to existing practice.
4) Motorola's 68K (<68020) terminology was sometimes confusing, because:
it clearly has a 32-bit ISA, with different databus sizes:
68000: 16 called 16-bit, or sometimes 16/32-bit
68010: 16 called 16/32, or sometimes 16
68008: 8 called 8-bit sometimes
Lumped together as a group, the term 16/32 was often used.
I'm not sure what was going on, perhaps the 32-bit ISA was taken for
granted, and the databus size sometimes crept in.
5) Summary: from an ISA and programmer's view, the most common
usage has long been the size of the integer registers, notwithstanding occasional marketing aberrations.
-john mashey DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL: ma...@sgi.com DDD: 650-933-3090 FAX: 650-932-3090
USPS: Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389
--
-John Mashey EMAIL: ma...@sgi.com DDD: 650-933-3090 FAX: 650-851-4620
USPS: SGI 1600 Amphitheatre Pkwy., ms. 562, Mountain View, CA 94043-1351
SGI employee 25% time; cell phone = 650-575-6347.
PERMANENT EMAIL ADDRESS: ma...@heymash.com
Keith R. Williams
Mashey) wrote:
> 1) Looks like time for a repost of the standard discussion, but succinctly:
It looked like a homework problem to me. I'm surprised at the
responses.
> historically, when people called a CPU "N-bits",
> the "N" normally meant the width the regular integer registers,
> NOT the width of floating-point or other special registers
> NOT the width of external busses
> NOT the width of other special datapaths
> NOT the size of instructions
..and *then* things get ugly. The NatSemi PACE meets your
definition of a 16bit processor. I do believe that would be the
first single chip processor to be "16bit".
----
Keith
George Macdonald
As others have noted a 128-bit CPU, meaning 128-bit registers, will only
show a benefit where you need to work with such large nunbers. For similar
architectures a program which runs happily on a 32-bit CPU, if recompiled
for the 128-bit CPU would run slower mainly because of cache pollution.
IOW you'd be filling up the cache with zeros as well as moving lots of
useless zeros in and out of the bus. IIRC a DEC/Compaq paper once
mentioned a speed degradtaion, all other things being equal, of ~15%.
Rgds, George Macdonald
"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Courageous
>useless zeros in and out of the bus. IIRC a DEC/Compaq paper once
>mentioned a speed degrad
I've seen offhand references to similarly small degradations in
AMD literature regarding Hammer (32->64 bit).
C//
Jukka Liimatta
Yup. I think/believe that 64bit pointer/address space will be most useful in
very large databases and such situations, anyone disagree?
Wider registers sure could come in handy in *processing* data.. since
registers are in most cpu's used for both purposes ( addressing and
processing ). I recall from my 68000 programming days that the An registers
were good mostly for addressing purposes, and using as temporary storage
where the Dn were more generic and had wider range of opcodes that they
could operate on.
On the other hand, the 386 and later X86 ISA's pretty much allow to use the
registers for anything interchangeably, except division and multiply which
for some odd whim of the original design only work with (e)ax and (e)dx.
Yadda yadda, 64bit wide register comes in handy, if for noting else more
accurate fixedpoint maths where that may be a better alternative than
floating-point.
I'd dare say the limits what is and what isn't XYZ bit processor are not
that obvious at times, better evaluate per case basis.. afterall, each are
individual "product", even if part of larger "family" of products. Wider
data elements like 128bit SIMD SSE registers in Intel Pentium III and later
models are A Good Thing.
A 128bit wide address wouldn't be that useful for most people, even 32bit
addreses are most adequate for MAJORITY of users -- until 4GB of memory
becomes commonplace on desktop. I am not saying there aren't plenty of
applications that won't need more than that of memory, doesn't take too much
imagination or knowledge to get that far -- but majority of *people*, like
office use, home users and like, I am sure, will be most satisfied with
32bit addressing for atleast next few years. ;-)
... back to original track-- somehow I got the impression that the question
meant "home pc", or "normal" desktop system, so the "number of bits" means
data element width(s), and the bus width to support it. To answer that, yes,
properly designed software should not have problems increasing performance
by 100% -- assuming there is a processing bottleneck. Certainly if the
application is copying files from point a to point b in hard-drive the
number of bits is not nearly as significant factor as the speed of the
hard-drive unit. But if you are for example crunching numbers, say,
transforming vectors, doing projections, square roots, inverse square roots
and likes, using SIMD will be a great boost to performance. Anything where
you can vectorize the data, basicly.
Maybe if he would tell us more about his application more precise answer
would be possible, instead of arguing what these bit widths of
microprocessors mean. I'm sure most of us here are atleast 15 years old so
we have a few years experience in the topic. Unless everyone read the same
reference manual, the answer will vary most people still meaning the same
thing. There should be a Universal Programmer's Quote Manual, which would
then put end to arguing what terms mean. Then again, precise use of terms
should be elementary, how else could engineers and other similiarly minded
people communicate effortlessly. So maybe it's good to set the record
straight... too bad it happens over, over, over, over and over again during
the days, weeks, months and years you follow the usenet. ;-----)
Long rant, apologies, all mistakes are mine. (c) jukka 2000
p.s. merry x-mas !!!!!!!!!
Courageous
>> I've seen offhand references to similarly small degradations in
>> AMD literature regarding Hammer (32->64 bit).
>Yup. I think/believe that 64bit pointer/address space will be most useful in
>very large databases and such situations, anyone disagree?
That's exactly right and one of the primary appeals of a 64 bit
architecture. There's also the issue of processing numbers in
larger chunks -- as has already been pointed out here -- which
will double the performance of certain algorithms, most notably
those related to encryption, but some others also.
The 64 bit machine is of little relevancy to the average user
today. Perhaps in a half decade or more when gigabyte ram
sticks start becoming standard it will mean more.
C//
ttk_ciar
> From: tor...@diku.dk (Torben AEgidius Mogensen)
> Date: 22 Dec 2000 12:45:28 +0100
>
>For some tasks (specifically tasks that require calculation with large
>integers, such as cryptography), a 128-bit CPU may be close to four
>times faster than a 32-bit CPU.
Everything you say is true, but you missed one: A 128x128->128
bit multiplier can multiply 128-bit integers in one operation,
whereas a 32x32->32 bit multiplier requires 64 multiplication
operations to multiply 128-bit integers. Most 32-bit microprocessors
actually have a 32x32->64 bit multiplier, though, which cuts it down
to only 16 multiplication operations.
-- TTK
John R. Mashey
|> The 64 bit machine is of little relevancy to the average user
|> today. Perhaps in a half decade or more when gigabyte ram
|> sticks start becoming standard it will mean more.
If all of the 64-bit micros in the world suddenly stopped working tomorrow:
1) Nintendo N64 users would be unhappy.
2) Users of many laser printers would be unhappy.
3) Anyone who used the Internet would be unhappy, because the Internet
would pretty much stop cold ... given that a large number of CISCO routers
use 64-bit CPUs...
4) Many people who need CAT or MRI scans would find they weren't getting them.
5) Much AOL email would stop.
6) And so would a lot of other things.
Perhaps these things are of little relevancy to the average user ...
hence, I think what the earlier posting meant, if said precisely, was:
the average user of PCs or Macs doesn't usually need to run 64-bit apps
in those devices...
which I'd agree with.