Athlon64??

John wrote:

The
Athlon64s will easily compete with top P4s.

http://www.xbitlabs.com/articles/cpu...hlon64_11.html

http://www.xbitlabs.com/articles/cpu...thlon64_8.html

Don't be so sure...
--

Stacey

John wrote:

Don't let Strontium draw you into a lengthy mess!

Don't worry. I think this question is done. I've read enough of this
group now to realize that talking with Strontium is pointless (e.g XP
& Dial Up networking).

I've made two posts that should answer all of the questions raised.

Actually because you post your OPINION that an AMD64 excells in a 32bit
environment doesn't make it so.

http://www.xbitlabs.com/articles/cpu...thlon64_8.html

Unless the shipping chip has some MAJOR clock speed increases, prescott is
going to blow it away.

--

Stacey

"Stacey" wrote
Actually because you post your OPINION that an AMD64 excells in a 32bit
environment doesn't make it so.

Unless the shipping chip has some MAJOR clock speed increases, prescott is
going to blow it away.

I thought the AMD 64 could run old 32 bit software great and the Intel 64
couldn't?

PS On the benchmarks, Intel _always_ aces AMD in multimedia encoding. It
will be interesting to see what the final release 64 motherboards can do for
AMD.

Guess I've got to read xbit labs' stuff.

--
Ed Light

Smiley :-/
MS Smiley :-\

On Fri, 4 Jul 2003 00:43:07 -0500, "Strontium"
wrote:

Poor AMD. Has to resort to 64bit technology to even 'touch' the P4 HT.
Sad, sad, sad.

?? Are you just very young, or... ;-)

(I'm biased too. I have two P4's. A 1.5MHz and a 2.4MHz. And I have
two Athlons. 700MHz and XP3000+. The 1.5MHz is, most of the time,
slower than the 700 it was supposed to replace. And on my main working
app, a very specialized 4D pathfinding app, the 3000+ is
_SEVERAL_TIMES_ faster than the 2.4GHz! I'll never, ever buy another
P4/P5. I bought my first P4 because I'm ignorant. I bought my second
because I'm stupid. I actually believed all that "Northwood" BS. I'll
quite happily buy Intel. Some Itanium, in that case. But never another
'media chip'. I want a real cpu.)


ancra

On Thu, 3 Jul 2003 06:27:34 -0500, "Strontium"
wrote:

What amazes me is that people seem to think that 64bit technology is Mecca.
It's been around, for a while, already. It's main usage being unix servers.
Why the general consumer would need it, baffles me. Yet another marketing
ploy, by the manufacturers. I doubt, very seriously, that you will have any
applications that will even use 64bit...regardless of whether the OS can
utilize it.

You do somewhere have an excellent point: '64bit' will not,
immediatly, in itself bring better performance than '32bit'. Nice to
see that someone understands that.
However, we do indeed need 64-bit app space, and we do need it now.
Further, the Athlon64 is not just a 64-bit CPU, it's AMD's next CPU
generation, the K8. For _that_ reason, it will be faster, regardless
of 32/64 bitness.

Applications will migrate into 64-bit as soon as they can. Win32 is
limited to 2GB app space and there's a ton of video-, engineering-,
simulation-, VR- and gaming opportunities to use much more. Look at
the cost of RAM. The time is right for 64-bit. There was a time when
some people figured there could never be any use for much more than
128-512KB. But they also couldn't imagine a PC being used for picture
editing. The answer is that the applications that will use the
available space will emerge. Pretty much immediatly too.

Today, I professionally use a Windows app that routinely use up
1-1.5GB application space. Win32 doesn't have more than 2GB. Any day
now, it's going to hit the roof and run out of space.


ancra

On Thu, 3 Jul 2003 16:36:37 -0500, "Strontium"
wrote:

JK stood up, at show-n-tell, and said:

Why do we need 32 bit processors? Why not use 16 bit processors
instead?
Did you enjoy using 16 bit processors? :-)

Nope, win95 sucked my ass. However, I was mainly using MAC's back in the
day, if you must know.

Well, _my_ Win95 ran way much better than, was it MacOS 7?, but never
mind... MacOS 7 was nice, in many ways. - Oh, well, sweet nostalgia,
sigh.

Win95 is a 32-bit OS and cannot be run on a 16-bit processor.


ancra

On Fri, 4 Jul 2003 00:40:39 -0500, "Strontium"
wrote:

That's a sad state, of affairs, when AMD has to resort to 64bit to
'compete'. Sad, sad, sad. I said 'bye bye', to AMD. Bye Bye.

I'm not sure you're receptive to good advice right now, but I'm going
to offer it anyway. You need to distance yourself and your own
feelings of personal achievements and triumph from Intels, and the
P4's.

I do agree however, that it would be sad if AMD fails. But I really
mean it.
It would be sad because competition is good.
It would also be sad because the Athlon is in many ways a much better
CPU. More complete. The P4 has an edge on the latest benchmark crop.
Streaming instructions and recompiled for the P4. But the Athlon is
faster on oldfashioned 386/387 code.
It would also be sad, because then the very neccessary and needed
conversion to 64-bit standard, will be just as too late, convoluted,
difficult, contorted and problemridden as the changeover to 32-bit
was.


ancra

On Fri, 4 Jul 2003 16:23:57 -0500, "Strontium"
wrote:

I'll speak when and where, I damned well please.

Fair by me. I'm 100% with you here.

But the main motivation behind your posts _IS_ an emotional personal
attachment to Intel, and a compulsive desire to dis AMD. That is
absolutely clear to all of us. Don't wear your keyboard denying that.

It's rather that, than having opinions, that makes your input somewhat
invalid, ...- in this particular thread. But I'm sure you and I could
have lots of fun in some advocacy group. ;-) Don't know if there is
any Intel vs AMD group. There kinda 'should' be one... ;-)


ancra

On 4 Jul 2003 03:25:21 -0700, (Majestic)
wrote:

Looking at AMD's roadmap, it looks like athlon 64 is here to stay on
desktop
(Well unless AMD goes bankrupt, Then maybe Apple will take over)
Of course 64bit system were avaliable in servers for quite some time
but
i dont think we all own a server at home!
It is a shift another shift in paradigm.
As intel move to the end of the 'pentium 4' (after 3.2ghz) roadmap, a
new pentium was anticipated in Q4 next yr (from what i read from
inquirer)
Maybe intel might enable 64bit on their pentium 5!

No. Intel may actually secretly have a compatible 64-bit design on
backburner, as a fallback, but it isn't the P5, the P5 is another
'P7-core' CPU, just as the P4. It cannot be made into 64-bit.
(P6-core being PentiumPro, PII, PIII, PIIIe, Xeon, Celeron, Tualatin)
(P5-core being Pentium and PentiumMMX)

Hey wait a minute, Intel would prefer a pubilcity stun to knock out
AMD...
so maybe they will better AMD by pushing out a 128bit processor!!

No. We ran out of space with 16 bits already before the IBM PC. It has
taken us 25 years to run out of space with 32 bits. If the technology
moves at the same exponential rate, Moores law and all that, in the
future, it will still take at least another 25 years (probably 50) to
run out of 48 bits, and we will have 64. This may be a good time to
explain these bit-thingys:

When we today talk about 16-, 32-, 64-bit, we are talking about the
length of the adress, used by any cpu-instruction to refer to data in
memory.

Thus it doesn't have anything to do with the width of the data being
manipulated. Early "8-bit" processors, performing instructions on
8-bit wide data segments, actually had 16-bit adressing as well, so in
our sense, they too were "16-bit" CPU's. The PC is still a byte
adressable architecture, so we still have one adress for each 8 bits
of data in memory. In many other ways, the "width" of our cpu's have
moved on. We have 64-bit wide databus since the Pentium, and
internally, todays cpu's have both 128-bit and 256-bit wide buses.
And, of course, we have 64-bit cpu registers for floating point and
extended instructinsets, besides the 32-bit integer registers. On dual
channel mobos, you could even make some claim that we have moved on to
a 128-bit wide databus.

But let's get back to the length of adress. The external adressbus is
actually 36-bit wide, as well. BUT the instruction set only uses 32
bits for adresses! A good way to get a grip on this is perhaps to look
back.

The first generation of 8-bit PC's (not IBM PC's, just PC's) used, as
already stated, 16 bits to adress data. This was direct hardware
adressing (later called real-mode), so the adress went straight out on
the adressbus, and enabled some byte in RAM. A big problem with this
is that only 64KB RAM can be adressed. Early homecomputers were thus
limited to max 64KB RAM.

Unfortunatly, someone then had a very stupid idea. Mobos with more
than 64KB were built. 128KB, even 256KB. The wider adressbus
originated from a chip on the mobo, where a contained static value was
combined with the 16 bits from the cpu's adressbus, to form a longer
adress. Any and each application using more than 64KB had to manage
the memory itself. It had to write the current page to the combining
chip, every time it went across a page border. And that is actually
quite awkward and bugprone.

The preferred OS at the time was CP/M. It worked just as DOS. It
simply loaded & launched the app and then went away, leaving all the
hardware directly to the app. Common cpu's at the time were Intels
8080-85 series, the compatible, but extended Zilog Z80 and the odd
one, the clever little 6502.

Intel then had some crazy stillborn cpu design in the works. (the '286
and the Itanium are by no ways unique for Intel). As it was becoming
increasingly clear that it was a failure, Intel began looking for a
savior.

They simply extended the 8080's 8-bit registers to 16-bits. This is
quite simple. You simply insert more of the same logic between the
carry and 0. You still have 16-bit adressing though. Doing something
about that requires a much more fundamental redesign. Longer
instructions need to be decoded etc. Instead Intel opted for a dirty
solution. They simply took the crude paged concept, I've already
described, and moved the combiner/pageregister into the cpu itself.
The 8086 was born. The 8086 had a 16-bit databus and a 20-bit external
adressbus and could adress 1MB. But code still used 16-bit adresses.

Unfortunatly, IBM then chose this abomination instead of Motorolas
vastly superiour 68000 cpu (it already had real 32-bit adressing!).
Much have been said and written about this incomprehensible choice.
Bill Gates have called it "the ultimate triumph of marketing hype over
science and engineering". I suppose he learned some real truths from
that, which he then has been able to exploit successfully in many
ways. ...And so did Intel.

For some obscure reasons, clueless PC journalists, far into the
nineties, often referred to 68k-cpu computers (Mac, Amiga, Atari,
Next, early SUN) as "16-bit", just as 8086 and '286 PC's. That's BS,
some 68k machines may have had only 16-bit mainboard databus, and some
(Mac) may only have used 24-bit adresses to begin with, but the 68k
cpu family was always 32-bit technology, right from the start.

The basic problem of the 8086 is that you need long pointers for
computing adresses in large dataobjects. But on the 8086, these long
pointers can't be used directly by an instruction since it's limited
to 16-bits. Instead a correct page has to be computed and set, and a
short pointer, into this page, has to be computed and used instead.
All of this must be done by the apps own code, inside the app. This
degrades performance horrendously, and is also extremely bugprone.

(Mind you, if you can use short pointers only, you don't suffer any
performance penalty from 16-bit code. This is partly why Win95 doesn't
suffer at all, despite having some legacy 16-bit code in the 'user'
API. Win95 still has to 'thunk' those 32-bit calls (from 32-bit apps)
to 16-bit calls, but the 'thunking' is compensated by win95 not doing
any context shifts during system calls.)

Another problem with the 8086 was that it could only adress 1MB.
Intels solution to that was the '286. This keeps 16-bit adressing, but
extends the paging scheme to produce a 24-bit external adress. So it
can adress 16MB. 286 adressing is extremely complex and the 286 is
generally rated as the worst CPU-design of all time.

The 286 made Bill Gates and Microsoft very upset. So annoyed, that
they drew up the wishlist for the 386's memoryhandling, memorymodes
and instructionsets and forced Intel to design the processor. Many
don't know this, but the 386 wasn't an idea originating inside Intel.
Microsoft persuaded Intel to build it to their desires. And very well
done by MS too, I think. All subsequent PC cpu, 486, Pentium, PII,
PIII, K6, K6-2, Athlon, P4, AthlonXP still use the 386
instructionset/memory architecture.
(The Athlon64 intends to break with that tradition. But it also
intends to stay backwards compatible, just like the 386 did.)

Finally, Intel had a real cpu, that could execute instructions using
32-bit adresses. 32bits are good for 4GB. A 32-bit app could finally
have a linear memoryspace. Which means that any adress arithmatic is
simple and straightforward.

The 386 also separates the adresses, used by the instructions in the
programcode, from actual adresses. It uses a complex paging scheme to
map hardware 'real' adresses, as they go out on the cpu's adressbus,
to software 'virtual' adresses, as used by the code instructions. The
information about the mapping is contained in something called
pagedescriptors. These typically reside in the cpu level1 cache. This
separation allows features that are called 'virtual memory' and
'protected memory', but that is a responsibility of the OS to
implement. It also allows the 386 to run both it's own 32-bit code as
well as 286 16-bit protected mode code and - in a special mode called
'virtual real mode' or 'virtual mode' for short - 8086 16-bit code,
concurrently, in the same OS.

AMD intend to re-perform the 386 trick, that brought linear adress
space and 32-bit adressing to the PC, yet another time. This time with
64 bits.
64-bits are about getting a bigger adress space for the app. Win32
only provides 2GB, and that is beginning to be a tight fit for a lot
of applications.

The Athlon64 will not be faster because it's '64-bit'. It's going to
be faster because it's AMD's next cpu generation.
Ultimately though, it's going to completely outperform 32 bit cpus,
like the P5, on big data apps, presicely because it's 64-bit. 32-bit
apps have to handle large data in a much more convoluted manner. Same
as some Win16 apps had to do, when they ran out of their 16MB space.
The performance penalty is going to be enormous.


ancra

Unless the shipping chip has some MAJOR clock speed increases, prescott is
going to blow it away.

The shipping chip will perform much better than a testing model. That
was rated at 2800+. These are the speeds for the release models:

*1800 MHz is 3200+
*1900 MHz is 3400+
*2000 MHz is 3600+
*2100 MHz is 3800+