64-bit P4 3.2/3.4/3.6Ghz: within a week!!!!

slvr_phoenix · Jul 30, 2004

Erm... there's new info on the main topic of this thread!

Oh, so that's how you stay on topic. Hey. I had always wondered how exactly it was done. 😉

Apparently, we'll be seeing 3.2, 3.4 and 3.6Ghz P4s with 64-bit extensions enabled and operational next week. I wonder if it will make benchmarking EM64T vs AMD64 easier, once the linux distros support EM64T better?... it seems that, after this launch, everything is in the programmers' hands.

I think that everything was in the programmer's hands from the beginning. The trouble is how do you program for hardware that you don't have? I haven't seen any indication that EMT64 is functionally different enough from AMD64 that it would require someone to actually use different programming. It's not that the Linux distros don't support EMT64. It's that the kernel they share doesn't support x86-64 without IOMMU in the northbridge / memory controller.

Still, without a 64-bit Windows retail release for x86-64, who really cares? I sure as hell wouldn't run my PC on a beta OS. (Or at least not an M$ beta OS anyway.)

I think the real question will be do any of Intel's northbridges have IOMMU...

<pre>"Build a man a fire and he's warm for the rest of the evening.
Set a man on fire and he's warm for the rest of his life." - Steve Taylor</pre>

slvr_phoenix · Jul 30, 2004

Sci-Fi/Fantasy... Somehow I'm quite unsuprised there!

Right! Go figure. A geek and a departure from reality...

Just the sort of stuff I like to read - if you ever want a second opinion on your stuff, I'd be happy to oblige! I'm forever running out of reading material....

That's a tempting thought. My wife has been rather slow on helping me proof read, and goodness is my spelling ever bad. (And sometimes my grammar.)

However, and I mean no offense, I am worried about people stealing my books and getting them published as their own work. I trust my wife, and I know where she lives. 😉 I think I'd have to snail-mail some sort of nondisclosure contract if I were to send anything out like that. (Though to be honest, I'm not sure what sort of legalities are involved in that.) But it might be fun to set up a THGC proofreader club or something like that. Then I could give props in the front of my books to someone other than just my wife. Heh heh heh.

Of course if you'd rather keep them all to yourself, as a personal project type-thing, then 'tis fine.

That raises another interesting point. Some of the books are in vague ways personal. I'll have to think on how I feel about that. Maybe that's been a subconscious motivator to keep myself from publishing. I don't know.

I would like to do some writing, but I can never think of a storyline that doesn't sound like I'm just ripping off lots of other stuff I've read... Ah well, in a few years perhaps...

Heh heh. Yeah. Exactly. I think that I started writing because I wanted some storylines that hadn't been done to death. But then I moved into writing books with storylines that had been done. I'm not sure if that's ripping off or not. **shrug** But it's kind of like music, the more that gets out there, the harder it is to be original. So maybe it's not ripping off at all. Maybe it's just a market-saturation repetitive disorder.

<pre>"Build a man a fire and he's warm for the rest of the evening.
Set a man on fire and he's warm for the rest of his life." - Steve Taylor</pre>

ChipDeath · Jul 30, 2004

However, and I mean no offense, I am worried about people stealing my books and getting them published as their own work.

Damn! There goes my get-rich-quick scheme.. :lol:

Seriously, I wouldn't do that personally... But then if I was going to do so, I would say that wouldn't I? 😱 So I fully understand that point of view...

I would offer to swap with some of what I've written over the years, but it's mostly Delphi code so is a bit thin on plot... :lol:

But it might be fun to set up a THGC proofreader club or something like that.

That would be good fun I think. Proofreading is one of my lesser-known talents (IMHO) - I could probably be of some use....

---
Epox 8RDA+ V1.1 w/ Custom NB HS
XP1700+ @200x10 (~2Ghz), 1.4 Vcore
2x256Mb Corsair PC3200LL/1x512Mb Corsair XMS PC4000 2.5-3-3-7
Sapphire 9800Pro @412/740

slvr_phoenix · Jul 30, 2004

amd did make it so hard for intel to make it compatible as you say they did, it must be amd's fault.

Hey, if Intel can build SSE, SSE2, SSE3, etc. instructions into their CPUs exactly according to their whitepapers, there's no reason why AMD can't do it for AMD64. So if there is a true incompatability problem (which I highly doubt), and it doesn't involve Intel wrongly implementing something from whitepaper, well, then who else is there to blame? As I have said, there is no indication whatsoever of compatability issues. But if there are some it will either be because Intel couldn't follow AMD's spec or AMD couldn't follow their own spec.

i do understand the stuff i have been reading, i just assuemd too much for intel is all.

The fact that you even still put any of this onto Intel's shoulders means that you still do not understand. It's that simple.

im am just waitng for the numbers so everyone settle the debate on what works and what doesnt, what performs well and what doesnt.

From a BETA OS?!

there are enough apps and drivers and such that a person could do a review for the nocona as soon as whatever incomptibility, i know oyu odnt like that word so i apologize, is worked out

Here are how many ways that you are wrong:
1) There obviously aren't enough drivers.
2) There is no incompatibility to work out. There is a lack of drivers on the M$ side, and an unnecessary dependancy on IOMMU support in the northbridge on the Linux side.
3) I don't have any problems with the word "incomptibility", or even with "incompatibility". I do have a problem with you insinuating/claiming incompatibility problems and insinuating Intel conspiracies when in fact that is not the case. I'd have just as much of a problem if you did the same for AMD, IBM, or even the ASPCA. I'd probably let Apple slide though. Apple has certainly lied enough in their advertising that it'd only be fair to lie about them.

your right, it must have been a poor substitute

You see, now you're even putting false words into my mouth. I never said that it was a poor substitute. I said that reviewers didn't trust it. I'm sure that they have their own reasons that may or may not be based in reality. Whatever the case, it was their decision. I can't really blame them I suppose. Enough cheating has been done by pretty much every company in existence in the past to make even the most trusting of reviewer a little cynical.

intle is pushing its desktop em64t chips very soon, so maybe we wil fianlly get to see some numbers.

I certainly hope so. Even still however, numbers from beta software mean less than the electricity used to paint their pixels.

i bet supplies of those will probably be even worse then the noconas.

That could very well be true. Or it could go the opposite route where because non-server chips have less stringent requirements there could be a lot more of them than there are Noconas. Time will tell.

P.S. To anyone enjoying my lyric quotes, it's hard to be inspired to quote songs when you're listening to instrumentals. (In this case Final Fantasy soundtracks.) Please forgive me for going so long without one.

<pre>"Build a man a fire and he's warm for the rest of the evening.
Set a man on fire and he's warm for the rest of his life." - Steve Taylor</pre>

slvr_phoenix · Jul 30, 2004

Damn! There goes my get-rich-quick scheme..

I doubt that you'd get rich off of any of my novels anyway. Maybe earn a little money. I don't know. Rich though, naw. I'm too bothered by the boringness of most of the 'best sellers' to write one myself. If I ever sell out and purposefully write a book that bad I just may have to shoot myself. **ROFL**

Seriously, I wouldn't do that personally... But then if I was going to do so, I would say that wouldn't I? So I fully understand that point of view...

It's that darned catch22. (I wonder where that phrase originated from.) Which is why I'd have to include legal paperwork. But of course would that paperwork hold any legal water? That I don't know. :\ Or I could just trust people and if anyone screwed me stalk them, hunt them down, and kill them in cold blood while they sleep. :O (Just kidding.)

I would offer to swap with some of what I've written over the years, but it's mostly Delphi code so is a bit thin on plot...

**ROFL** Yeah. I know what that's like. Though actually a lot of my Python sourcecode is from my more recent (less sane) days and has comments that might make it more interesting to read. Example:

def __init__(self, *args):
""" Constructor.
"""
# And he held the UI file up on high saying 'let there be a window', and behold, a window there was.
apply(archiveproject_ui.ArchiveProject_UI.__init__, (self,) +args)

# Gimme, gimme, gimme that old time captioning.
connection = self.connection()
if connection is not None:
samplename = tables.Sample(connection).getCurrentSample()['sample_name']
self.setCaption("Archive Sample " + samplename + " To CD")
# end if

# Hey, who knew that there were burn devices attached to this box? Whadda ya know, a list of em all for me.
self.__devicelist__ = cdburn.getDevices(cdburn.MEDIA_CD_WRITER)

# Only the worthy may hold the holy relics of the device and location without being consumed by the immortal flame.
dev, loc = self.getDevAndLoc()
self.__device__, self.__location__ = self.getBurnDeviceAndLocation(dev, loc)
self.valididateBurnDeviceAndLocation()

# On second thought, don't center the numbers in those progress bars. It makes my stomach turn.
# self.m_progTotal.setCenterIndicator(True)
# self.m_progCurrent.setCenterIndicator(True)
# self.m_progBuffer.setCenterIndicator(True)

# Huh. Defaults. Hey, who knew?
self.__numCDs__ = 0 # Used for total progress calculations.
self.__currCD__ = 0 # Used for total progress calculations.
self.__xmlDump__ = None
self.m_editUsing.setPaletteBackgroundColor(self.paletteBackgroundColor())

# Sanity may be but a state of mind, but good user interface is eternal. Let those who are too stupid to find the X button in the
# upper right corner and the close menu uption of the icon in the upper left corner still be able to close the Window.
self.m_btnClose.setEnabled(True)
# end def

See? Comments can make source code fun.

That would be good fun I think. Proofreading is one of my lesser-known talents (IMHO) - I could probably be of some use....

I'm definately thinking about it. One of my biggest pet peeves is a lack of proofreading in 'professional' publishings. In my opinion the more proofreading the better.

And since (by example of printed books) I can't trust any publisher to do a good job of it...

<pre>"Build a man a fire and he's warm for the rest of the evening.
Set a man on fire and he's warm for the rest of his life." - Steve Taylor</pre>

Mephistopheles · Jul 30, 2004

P.S. To anyone enjoying my lyric quotes, it's hard to be inspired to quote songs when you're listening to instrumentals. (In this case Final Fantasy soundtracks.) Please forgive me for going so long without one.

Oh yeah, the almighty Nobuo Uematsu! 😎

You never change the existing reality by fighting it. Instead, create a new model that makes the old one obsolete - Buckminster Fuller

trooper11 · Jul 30, 2004

But if there are some it will either be because Intel couldn't follow AMD's spec or AMD couldn't follow their own spec.

see now thats mroe fair, the reason i pointed htis out before was becuase you seemed to only mention that fact that if it was compatible, that it had to be amd at fault, it could be either side, and there may be no incompatibility.

From a BETA OS?!

what is so hard ot belive? why on earth has any of these review sites done any reviews on amd chips using a BETA OS? if your going to say its uselless to evne show suhc numbers, then why evne be intersted in seeing any numbers with amd? and yet ppl do want to see the numbers, evne if it is a BETA OS. and also there is linux, once there is a working equivilent for testing, id like to see what it can do. just becuase windows is beta doesnt stop ppl form testing, i mean its been going on for the past year with amd, intel should be no different. maybe yout hink no one should have been testing the amd chips wiht a beta os, if so then i would agree. it should be level, either boht test on the beta or niehter do, becuase one without the other just doesnt help anything.

i was not trying to insenuate anyhting about intel, your reading too much into my comments. i dont think intel would do this on purpose, there simply isnt the software infrustructure there yet to make any kind of em64t review plausible. i just want to knwo why you think there is absolutely no possibility that intel might have deicded to goa different route then amd as far as 64bit goes. im nto trying to say soemhting bad about intel, but its not like they care wether they mimic amd or go thier own way. there is just as likely a chance that its not incompatible and just the few things we talked about here are all it will take to get things going, but the fact is, there is no proof to say one is right over the other. ill wait patiently to see the results, then we will see just what the hold up was.

im excited to see the show down, this is a highly charged area for lots of people, wiht all the rumors that are floating around, it will be nice to finally get to some facts. surely most of the neccesary drivers will be out in a relatively short time, i dont see why it would take more then a month to get such things out, unless the comapnies in charge of those drivers hit problems or push it ot the back burner for now.

Mephistopheles · Jul 30, 2004

If indeed there are 3 different P4s due next week (3.2, 3.4 and 3.6Ghz versions with EM64T enabled) then at least the 3.2 and 3.4 versions will probably be available quickly. I don't know about the higher-clocked 3.6, but at least it'll be easier to see EM64T enabled....

BTW, yuo hvae na extordinary lteter exhcange raet... Better wathc uot fro thsoe lettesr, tehy kepe miixng thmeselves! (sorry, I couldn't resist, don't take me the bad way)

The funniest thing about that is that even when letters are mixed up, you can still make sense of the whole sentence easily and quickly...

You never change the existing reality by fighting it. Instead, create a new model that makes the old one obsolete - Buckminster Fuller Edited by Mephistopheles on 07/30/04 07:43 PM.

P4Man · Jul 31, 2004

>The two x86-64 instruction sets are functionally identical
>enough that the initial 64-bit beta for Windows would run
>on Nocona. That wasn't the problem. The problem was that
>the installer was specifically written to check for an AMD
>chip before installing.

Ahem.. no, not likely. That is MS doing intel a favour if that is what they say, but reality is a bit (though not much) different. See several 64 bit Linux distro's, which don't check for "Genuine AMD" or something, yet can't be installed on Xeon64 either. The reason is an eratum where Nocona when queried claims to support 40 bit addressing (like K8) while in fact in only supports 36 bits. That's a minor issue, and easily patched, but its not because MS messed up, intel did.

>Furthermore there was no functional difference between the
>two x86-64 instruction sets that prevented it from running
>on Linux either. What prevented the proper Linux kernel
>from running Nocona was not an EMT64 instruction set
>problem. It wasn't even a CPU problem. It was a northbridge
>problem in that Intel implemented a solution different from
>IOMMU to solve the >4GB DMA memory addressing 'problem'. A
>'problem' which frankly isn't really a problem at all.

Again, slightly incorrect AFAIK. The problem is not the northbridge, its the cpu that claims to support 40 bits addressing, while it can't, which roughly causes the problem you described. The erratum is documented, and already implemented in some distro's, I have no doubt the others and Windows will follow suite, but the problem (however minor) *is* Nocona related.

>And in fact even right now Nocona can run the 64-bit beta
>of Windows

Not unless you have the newer release which is under NDA. The public beta doesn't run on Nocona, it fails to install. Nothing to do with drivers either..

>Again, not a single expert disagrees with any of this, so
>why are you seeing nonexistent incompatability problems
>when no expert is saying that there are any?

There are. I assume you don't take my word for it, so I'll see if I find the time and energy to dig up the links tomorrow.

>Considering that Intel implemented the instruction set
>according to AMD's white papers, the only possible
>incompatabilities that could arise would be those created
>by AMD when they didn't follow their own white papers

LOL! Seriously, AMD could screw up, but intel could not ? Every chip has its bugs, opteron has plenty, and so had Nocona. None that i'm aware off that could lead to application level incompatibility, but the one mentioned above does make Nocona "incompatible" (overstatement but true nevertheless) on a OS level.

>Seriously though, what does Intel really have to gain from
>trying to promote Nocona? No released 64-bit Linux distro
>runs it. No released 64-bit retail Windows OS runs it. So
>no OS that any business would trust their precious server
>to runs with Nocona's EMT64.

I guess that is why all those fortune 500 companies are testing Nocona with 64 bit windows and Linux? Cause I tell you, they are.

>So again, there is no x86-64 instruction set
>incompatability causing the review delays. It is that the
>graphics drivers are missing for Windows, and that the
>Linux kernel is still dependant on a northbridge
>instruction missing from Intel's chipsets. There's no
>conspiracy. There's no instruction incompatability. It's
>just simply a software mess.

Mostly.. except for that minor eratum which causes Nocona to not install/boot current windows beta. If it did, it would be in the same software misery as opteron though.

One thing that has not been mentioned though, is performance. I agree there is no reason to assume Nocona will be incompatible (minor issues asside), but that doesn't mean that Nocona will enjoy the same speedup as Opteron. In fact, there are many indications to the contrary (like that MS guy saying "one company implemented it all the way, and the other not"). How much of a difference there will be is anyone's guess, but i'm curious like anyone else to see some 64 bit benches of intel latest. I've got a hunch Nocona may turn out slower in 64 bit mode than in 32 bit mode.

= The views stated herein are my personal views, and not necessarily the views of my wife. =

IIB · Jul 31, 2004

That information is old...
in the recent quarter finanical result press meeting, AMD itself stated it would start shipping 90nm products for revenue this quarter (Q3).
so we will defently see 90nm products before the end of the year.
in recent AMD roadmaps the FX55 and Athlon 4000+ are expected to launch Q4 of this year. those might be based on 130nm.

Inntresting to note that while intel pushed 4Ghz P4 from Q4 Y4 to Q1 Y5, AMD moved the FX 55 and A64 4000+ from the Q1 Y5 to Q4 Y4...

This post is best viewed with common sense enabled

Johanthegnarler · Jul 31, 2004

Could you give me a small summary of what just happened.
Help me help you.

<A HREF="http://arc.aquamark3.com/arc/arc_view.php?run=277124623" target="_new">http://arc.aquamark3.com/arc/arc_view.php?run=277124623</A>
46,510 , movin on up. 48k new goal. Maybe not.. :/

phial · Jul 31, 2004

P4 3.8Ghz with EM64T is due to be launched on the first of august?...

launched, or "announced"?

paper releases are funny

-------
<A HREF="http://www.albinoblacksheep.com/flash/you.html" target="_new">please dont click here! </A>
<A HREF="http://www.subhi.com/keyboard.jpg" target="_new">This is you, interweb junky</A>

Mephistopheles · Jul 31, 2004

I think a whole lineup of 3.2, 3.4 and 3.6Ghz P4s are going to be launched with 64-bit extensions, according to news. Even if the 3.6Ghz isn't that readily available, I'm pretty confident the other two will be available... Or at least I hope so, I'm curious as to how P4s with 64-bit perform against A64 tech.

You never change the existing reality by fighting it. Instead, create a new model that makes the old one obsolete - Buckminster Fuller

JJKP77 · Jul 31, 2004

Could it be that with these incompatibility issues(em64t), Intel is just miphed that
AMD no longer has to follow suit to them and they are just showing thier ass?
Think about it. AMD has always been the tag along in processor design.
Now intel is doing what they always have, they are leading the way.
unfortunately for them, no one took the time to tell them the way
has already been lead and that they need to get thier $h!t together, suck it up,
put on a happy face and deal with the fact that this time they are the tag along.
Silly market dominating intel... so silly. LMAO @ Intel and pointing. I
don't think they get the fact that whether or not they respect AMD the rest of the world
does, including Microsoft. To piss on Microsoft is not a good idea for a proc manufacturer
when its all said and done at the end of the day. even if the said proc manufacterer
does dominate the market.

AMD Athlon XP 2100+-=-1Gb PC2700-=-40Gb WDD HDD-=-
16x DvD-=-32x12x40 Lite on CD/RW-=-Floppy, "Who needs a damned floppy!"-=-ECS K7S5A Pro-=- Geforce 4 Ti 4400 128Mb 4x-=-

P4Man · Jul 31, 2004

Here are the links I promised:
<A HREF="http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=20289129" target="_new">http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=20289129</A>

<A HREF="http://developer.intel.com/design/xeon/specupdt/30240201.pdf" target="_new"> Intel PDF </A>

= The views stated herein are my personal views, and not necessarily the views of my wife. =

Johanthegnarler · Jul 31, 2004

Actually at the time the site must have been down or something i see it now. Interesting indeed.

<A HREF="http://arc.aquamark3.com/arc/arc_view.php?run=277124623" target="_new">http://arc.aquamark3.com/arc/arc_view.php?run=277124623</A>
46,510 , movin on up. 48k new goal. Maybe not.. :/

slvr_phoenix · Aug 2, 2004

Ahem.. no, not likely.

Ahem, sorry, but extremely likely. Your condescending sarcastic attitude does little to make you sound any more credible than it ever did before. As someone who makes a lot of installations for test distributions I completely understand putting such a check in. They wanted the beta tested on a specific hardware platform. If a bug report comes in it becomes very important to know exactly what hardware is involved. So when M$ says that they hardcoded that install for AMD CPUs, I completely believe them. I don't trust M$ any further than I can throw their corporate headquarters, but in this one thing I believe because I know from personal experience what that's like.

See several 64 bit Linux distro's, which don't check for "Genuine AMD" or something, yet can't be installed on Xeon64 either.

Try to stop ignoring already stated facts. The kernel that these distros is based on requires IOMMU, a feature in the memory controller / northbridge that allows PCI cards to have DMA access to >4 GB of RAM. It has nothing to do with x86-64 instructions at all, and is exactly why these Linux distro's won't work on Intel's motherboards that don't have IOMMU logic in the northbridge.

The reason is an eratum where Nocona when queried claims to support 40 bit addressing (like K8) while in fact in only supports 36 bits.

Actually, I haven't heard of a single source yet which states this as actually being any sort of a problem for anyone. As you yourself said, it is minor. It is easily worked around. There is no problem there. In as no one is even hitting 64GB as an address space limitation, it will not be a problem either.

Again, slightly incorrect AFAIK. The problem is not the northbridge, its the cpu that claims to support 40 bits addressing, while it can't, which roughly causes the problem you described. The erratum is documented, and already implemented in some distro's, I have no doubt the others and Windows will follow suite, but the problem (however minor) *is* Nocona related.

As you said, that is as far as you know. I'm telling you now, you're wrong. You're dead wrong. It is IOMMU requirement on Linux and it is a combination of a hardware check and a lack of drivers on Windows. That's not "as far as I know". That's as far as every expert knows. Just try using Google for once. The information is out there if you bother to look.

Not unless you have the newer release which is under NDA. The public beta doesn't run on Nocona, it fails to install. Nothing to do with drivers either..

Now you're just getting plain stupid. No one ever said that the publicly available beta ran on Nocona. It is the pre-installed beta which ran on Nocona, a beta which M$ has chosen not to make public yet. And no one ever said that the public beta wouldn't install because of driver problems. It won't install because of a hardware check. It won't run a decent graphics card because of driver problems. Stop being so stupid. This information is all available and as clear as day even in this thread as well as numerous sources on the internet. Your pathetic twisting of words into illogic are just plain stupid. IF you have something to debate, then try doing it well for a change. Otherwise stop annoying people with your garbage.

There are. I assume you don't take my word for it, so I'll see if I find the time and energy to dig up the links tomorrow.

No, I'm sorry, but there aren't. The 36/40 bit bug is not any sort of a serious impediment. No one is even worried about it. It's well documented by now and frankly, no one really cares. It's plain ridiculous to even think that anyone is worried or impeded by it. The real issues that every expert agrees on have already been stated, and the 36/40 bit piece is not one of them.

LOL! Seriously, AMD could screw up, but intel could not ? Every chip has its bugs, opteron has plenty, and so had Nocona. None that i'm aware off that could lead to application level incompatibility, but the one mentioned above does make Nocona "incompatible" (overstatement but true nevertheless) on a OS level.

1) Your pathetic clinging to this singular non-issue is truly sad. It doesn't make "Nocona "incompatible" ... on a OS level". It's a minor errata requiring an incredibly simple workaround that frankly wasn't even going to cause any bugs until a program tried to access over 64GB of memory.
2) As you failed to account, I already have corrected my statement in a later thread that any incompatibility issues that occur are either from Intel not implementing the white paper correctly or from AMD not following their own white paper. Your obvious and deplorable attemt to even try to turn this into an Intel/AMD fanboy argument is loathsome.

I guess that is why all those fortune 500 companies are testing Nocona with 64 bit windows and Linux? Cause I tell you, they are.

Do you even know how many ways you're wrong here? I bet you don't. I also bet that you don't have a single scrap of evidence.
1) Except for software development companies and equipment manufacturers (OEMs) there is no one testing this at all. Most companies leave that up to the OEMs to handle.
2) Software compatability testing (done by the small amount of software developing companies) is a completely different test than system stability/durability qualification (done by a large number of companies) and can be started with a productive beginning on beta software (so long as it is finished on final release software), where as system stability/durability qualification cannot.

Here are the links I promised:
http://www.siliconinvestor.com/stocktalk/msg.gsp?msgid=20289129

Intel PDF

Congrats, you can drag up a link for the 36/40 bit errata which is already common knowledge and no one ever debated its existence. You can also prove your incompetence at linking to a 404. Brilliant. You're my hero.

Page Not Found

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please check the address bar to make sure the link is typed correctly, use the links below to locate the information you want, or search the site for another destination.

One thing that has not been mentioned though, is performance. I agree there is no reason to assume Nocona will be incompatible (minor issues asside), but that doesn't mean that Nocona will enjoy the same speedup as Opteron. In fact, there are many indications to the contrary (like that MS guy saying "one company implemented it all the way, and the other not"). How much of a difference there will be is anyone's guess, but i'm curious like anyone else to see some 64 bit benches of intel latest. I've got a hunch Nocona may turn out slower in 64 bit mode than in 32 bit mode.

This would be the first intelligent thing that you've said in this post. You're right. You're exactly right. Performance has not been mentioned. Performance is the reason why benchmarking on a beta OS means absolutely nothing. There is a huge difference between software being functional and software being optimal. Besides being functional instead of optimal, betas also include countless amounts of debug code which slow them down even further. This is why any benches on the Windows beta are meaningless.

As for if Nocona will run any better in 64-bits, that's hard to guess of course. My theory is that if Intel didn't include the extra registers that AMD did, Nocona will likely perform exactly the same in 32 or 64 bit. All of those extra transistors in Prescott's core logic are for a reason. If you have to handle double the bits, then you need (approx.) twice the transistors. There is evidence of this being the case, hence it is likely that the performance will be identical between 32-bit and 64-bit.

The sole exception is that 64-bit software will be using twice the memory bandwidth for integers (so on average about 1.5x total memory bandwidth) on the same hardware and therefore that may cause the memory subsystems to perform somewhat slower. Since the P4 core is bandwidth-critical it remains to be seen how much this will hinder Intel's efforts. However, since Intel's primary concern is Itanium, I doubt that Intel cares. In fact they may even be happy if they can continue to give a reason for choosing Itanium over Xeon, even if Opteron clouds that reasoning.

<pre>"Build a man a fire and he's warm for the rest of the evening.
Set a man on fire and he's warm for the rest of his life." - Steve Taylor</pre>

slvr_phoenix · Aug 2, 2004

Oh yeah, the almighty Nobuo Uematsu!

Damn straight! If you can't project the emotions of the music across without the lyrics then you might as well not have written it at all. (Okay. So maybe that's a bit extreme.)

That is however a problem with so many 'composers' (and I use that term loosely) these days. Final Fantasy may have been limited by synthesizers instead of real instruments, but damn if that music doesn't kick the arse off of half of the other crap written today. A lot of video games are good for that. It's sad, but in these demented wars that parents hold to ban video games they may very well be fighting for the removal of the only good music that their children will ever be exposed to. :O

But I am being harsh. Crap has it's own merits.

Sometimes you just have to get stupid. Sometimes I'd rather have Kool-Aid than wine. Sometimes I have hot dogs instead of steak. (Though I really miss my Vienna Beef hot dogs.)

And other times I just really need some good Nobuo Uematsu to cleanse the palette.

<pre>"Build a man a fire and he's warm for the rest of the evening.
Set a man on fire and he's warm for the rest of his life." - Steve Taylor</pre>

P4Man · Aug 2, 2004

> I don't trust M$ any further than I can throw their
>corporate headquarters, but in this one thing I believe
>because I know from personal experience what that's like

Believe what you like, but I choose to believe not even MS is stupid enough to query for a cpu indentification string and then bluescreen when that doesn't result in "K8". Whats the point of such a check in the first place, if not to display an "incorrect cpu" message ? If you wanted to make sure the installed cpu supports everything needed to run XP64, you check for the capabilities, not the CPUID. If you want to prevent a user from installing it on hardware that is not compliant/tested, you display an error. And if you don't care about either, you don't check, you just assume it runs on Opteron (or anything completely compatible). This makes zero sense.

>The kernel that these distros is based on requires IOMMU, a
>feature in the memory controller / northbridge that allows
>PCI cards to have DMA access to >4 GB of RAM

Linux kernel 2.6.5 has supported software IOMMU for many months, yet distro's based on it, didn't boot Nocona either. What you state is Red Hat's reason to not to endorse their release on Nocona, and I'm sure its a perfectly valid reason, but its not the reason (other) Linux (distro's) doesn't boot (even with less than 4 GB, in which case only it might cause trouble as you pointed out).

>Actually, I haven't heard of a single source yet which
>states this as actually being any sort of a problem for
>anyone.

It is not a big issue, stop pretending I ever claimed that, but it is the most likely reason all existing x64 OS's do not boot Nocona without a patch. And don't tell me you believe every Linux distro as well as windows would implement something as stupid as a CPUID check, and crash if that doesn't return opteron's.

> That's as far as every expert knows. Just try using Google
>for once. The information is out there if you bother to
>look.

.. but it requires interpretation which you seem to lack.

> It's a minor errata requiring an incredibly simple
>workaround that frankly wasn't even going to cause any bugs
>until a program tried to access over 64GB of memory.

Bullshit. DO you claim to know exactly how the VMM does address translation ? The algorithm used to allocate memory ? I also know for fact older versions loaded top-down, so its quite likely this bug would cause windows to fail regardless of the ammount of memory installed.

>Now you're just getting plain stupid. No one ever said that
>the publicly available beta ran on Nocona.

You're the one that said:

And in fact even right now Nocona can run the 64-bit beta

. Considering the context, the disclaimer "publically available" should not have been omitted. Referring to "the 64 bit beta" implies there is only one, and if there is one, it is the current available beta.

As for me being stupid or not knowing, don't be such a jackass, I even mentioned the patched beta runs it, and I should know, I've seen it run.

>No, I'm sorry, but there aren't. The 36/40 bit bug is not
>any sort of a serious impediment. No one is even worried
>about it. It's well documented by now and frankly, no one
>really cares. It's plain ridiculous to even think that
>anyone is worried or impeded by it

Got a reading comprehension problem, don't we ? Reread my post, and please point out where I said or implied it was anything else. And while doing so, try hard to ignore the 5x I pointed out myselve it is indeed a minor issue. Sheesh. But it is by far the most likely reason existing AMD64 OS's do NOT RUN ON NOCONA.

>Do you even know how many ways you're wrong here? I bet you
>don't. I also bet that you don't have a single scrap of
>evidence.

I don't hmm. well, <A HREF="http://www.arnnet.com.au/index.php/id;616404470;fp;1024;fpid;98765" target="_new"> here goes </A>. Maybe the bank of NY is an oem these days ? I also tell you (but expect you not to believe) I've seen Nocona hardware running windows and Yucon at a customer of mine (schlumberger in case you're interested).

>1) Except for software development companies and equipment
>manufacturers (OEMs) there is no one testing this at all.

"this" ? I told you Nocona and windows for it are being tested, that's all I told you. Did I say everyone was proofreading the windows source code and checking the installation procedure for CPUID checks or something ?

For someone who so much loves shouting how stupid I must be, (without providing any evidence to the contrary really), I must say I'm impressed you dare spout nonsense such as:

>The sole exception is that 64-bit software will be using
>twice the memory bandwidth for integers (so on average
>about 1.5x total memory bandwidth) on the same hardware and
>therefore that may cause the memory subsystems to perform
>somewhat slower. Since the P4 core is bandwidth-critical
>it remains to be seen how much this will hinder Intel's
>efforts.

That is probably the dumbest comment I read whole day. Integer don't get twice as long, in 32 bit mode you can process 64 bit integers just as well, and they are just as big. In 64 bit mode, the default data size for integer instructions is still 32 bits. Not a thing changes there.

But if you want your instructions to use 64 bit ints, you need to set the REX prefix which makes the instructions themselves one byte longer, that is where the difference is (and obviously the use of 64 bit pointers)). Codesize increase is less than 5-10%, not anywhere near 1,5x, and has nothing to do with operand size. But someone as clever and all knowing as you surely knew that already.

Anyway, I am gettng a deja vue here. You don't want to discuss anything, you just want to pick a fight, throw around insults and pretend you're all knowing or something. Go waste Xeon's time, he's an easier target and I'm not interested in playing your games. if you're bored, get a hobby, a life.. seek friends or something.

= The views stated herein are my personal views, and not necessarily the views of my wife. =

phial · Aug 2, 2004

fight fight fight!

-------
<A HREF="http://www.albinoblacksheep.com/flash/you.html" target="_new">please dont click here! </A>
<A HREF="http://www.subhi.com/keyboard.jpg" target="_new">This is you, interweb junky</A>

trooper11 · Aug 2, 2004

you know im getitng tired of all these discussions, i wish intle or ms or whoever it is would just let the beta out.

what is so wrong wiht comapring amd64 to em64t both on beta platforms? i mean whats differnt here then anyone doing testing the amd64 now? you think that was wrong too? it doesnt do any harm to do testing now, if a person takes those results as the end all answer, then thats thier fault. information never hurt anyone, its how ppl use it or view it that affects things. if i had the money to just blow on a new system i would do it, but of course if the answer is that only an nda win64beta is the onyl way of running it, then of course no one can know. ill be waiting for a linux fix.

i agree that intel cares little about x86-64, they never wanted this, that is very clear. im sure they dont care if ms64 is delayed till next year, they didnt want 64bit in the first place. but i belive a working beta will be released this week, with the stories of ms releasing a new beta at the time intel announces the xeon and p4's with em64t.

Xeon · Aug 3, 2004

Go slvr I grow tired of argueing with him all time.

Xeon

Post created with being a dickhead in mind.
For all emotional and slanderous statements contact THG for all law suits.

Groveling_Wyrm · Aug 3, 2004

LOL!!! FLAME ON!!!!

er....um......

 Did you know that 89.72% of all quoted statistics are false?

slvr_phoenix · Aug 4, 2004

Believe what you like, but I choose to believe not even MS is stupid enough to query for a cpu indentification string and then bluescreen when that doesn't result in "K8". Whats the point of such a check in the first place, if not to display an "incorrect cpu" message ? If you wanted to make sure the installed cpu supports everything needed to run XP64, you check for the capabilities, not the CPUID. If you want to prevent a user from installing it on hardware that is not compliant/tested, you display an error. And if you don't care about either, you don't check, you just assume it runs on Opteron (or anything completely compatible). This makes zero sense.

We are talking about M$, remember? Zero sense is their business model.

Linux kernel 2.6.5 has supported software IOMMU for many months, yet distro's based on it, didn't boot Nocona either.

Gee, I wonder why. (Or not.) Maybe because Intel implemented their own (silly) workaround in place of IOMMU, and the combination of the two results in a mess? No. Never that. As I said, kernel dependancy upon IOMMU is the likely problem, whether that IOMMU implementation be hardware or software makes no difference.

It is not a big issue, stop pretending I ever claimed that

...

Got a reading comprehension problem, don't we ? Reread my post, and please point out where I said or implied it was anything else.

Right. You only repeated it like a broken record while ignoring all other explanations patently. <sarcasm hat>No, you never even so much as implied that it was ever anything else than an easily overcome minor issue that shouldn't have been capable of stuffing up every OS that has tried to run it. Not once did you try to give it even a hint of more import than that.</sarcasm hat>

Face it, if you can't even support your own arguments then how can you possible hope to refute mine? Just give up already.

Considering the context, the disclaimer "publically available" should not have been omitted. Referring to "the 64 bit beta" implies there is only one, and if there is one, it is the current available beta.

Could you get any more picky over semantics? Considering that no one in the world would believe that there is one and only one version of the beta, your argument is yet another example of the weakness in your debating skills.

I don't hmm. well, here goes . Maybe the bank of NY is an oem these days ? I also tell you (but expect you not to believe) I've seen Nocona hardware running windows and Yucon at a customer of mine (schlumberger in case you're interested).

Have I ever told you that you are brilliant? No? Gee, I wonder why...

In your effort to counter my point that the only Fortune 500 companies that are testing Nocona's 64-bit capabilities are those doing software development or are OEMs, you provide me with a <A HREF="http://www.arnnet.com.au/index.php/id;616404470;fp;1024;fpid;98765" target="_new">link</A> stating that the Bank of New York is testing "a statistical trading algorithm", thereby completely destroying your counter to my point. Stunning work there! You do know what an algorithm is, don't you?

But it gets better than that, because this very article also states "During the operating system installation process, Windows checks to see whether or not it is being installed on an AMD system. If it is not, the software cannot be installed", thereby also defeating another of your arguments. Amazing!

And to top off the help that you have given me the article also states "AMD also uses two instructions designed to improve Opteron's ability to quickly switch back and forth between applications. The additional instructions were added after AMD published its design papers that Intel used to create the architecture for the Nocona chip." which only goes back to support my argument with trooper11 that AMD could (and now we have proof that they in fact did) implement x86-64 differently from their own whitepapers, thereby creating x86-64 flavor incompatibilities.

You're my hero, P4man! If everyone debated with me with the same skill (or lack thereof in your case) I'd never lose. Thanks to you my job is done. You've validated my points while trying to prove me wrong, which not only invalidates your ability to argue these points logically, but also speaks strongly against your ability to debate in general. (Which, coincidentally, is another of my arguments.) Just give it up before you dig your hole any deeper.

(This is moved here because the latter part of the response requires the proof in your link.)

And don't tell me you believe every Linux distro as well as windows would implement something as stupid as a CPUID check, and crash if that doesn't return opteron's.

Why would I tell you something contradictory to that which I said in the first place over something which I did say in the first place? I said that for Linux it was requirement of IOMMU and I still stick to that. Remove IOMMU dependancy and then we'll see. But your own link now gives me even another argument. If the kernel uses the instructions that AMD added to their CPU but left out of their whitepaper, then AMD created an x86-64 base incompatability which would crash the kernel.

Did I say everyone was proofreading the windows source code and checking the installation procedure for CPUID checks or something ?

Did I? Other than trying to debate points which don't exist and thereby continue proving your inadiquacy to continue this debate, what are you trying to accomplish here?

That is probably the dumbest comment I read whole day. Integer don't get twice as long, in 32 bit mode you can process 64 bit integers just as well, and they are just as big. In 64 bit mode, the default data size for integer instructions is still 32 bits. Not a thing changes there.

<sarcasm hat>Right. So the use of 64-bit integers in 64-bit software doesn't use twice as much memory as using 32-bit integers.</sarcasm hat> It's funny how every single time you try to counter me you have to twist words into something other than what I said. Did I say that hybrid software running in 64-bit mode and using mostly 32-bit integers would increase the memory usage? No. So why then did you argue that instead of arguing what I actually said?

But if you want your instructions to use 64 bit ints, you need to set the REX prefix which makes the instructions themselves one byte longer, that is where the difference is (and obviously the use of 64 bit pointers)). Codesize increase is less than 5-10%, not anywhere near 1,5x, and has nothing to do with operand size. But someone as clever and all knowing as you surely knew that already.

And now you argue code size when I specifically stated memory bandwidth? Yet again another truly phenominal example of your inability to debate.

Anyway, I am gettng a deja vue here.

<sarcasm hat>No? Really?</sarcasm hat> Maybe if you learned how to debate or actually used logic (or for that matter were even right) it might be different for a change.

You don't want to discuss anything, you just want to pick a fight, throw around insults and pretend you're all knowing or something.

No, I'm both debating and simultaneously pointing out your inability to do so. A wise person would take that advice and stop bothering while they learn how to debate. (And for that matter learn how to use scripting in this forum already.) And perhaps if you weren't so worthy of insult you wouldn't recieve them so often. Furthermore, I never claim to be all knowing. I readily admit that I can and do make mistakes. (Any software engineer that doesn't should be shot, as no initial code is ever bug-free.) Anyone who can actually prove me wrong is more than welcome to do so. In fact, I welcome the opportunity. (Which is, perhaps, why in the past I have given you and your pathetic inability to debate effectively so much leniency.)

Go waste Xeon's time, he's an easier target and I'm not interested in playing your games.

If you're not interested then why do you keep replying?

And Xeon, after proof of his debating skills are you going to take that from him?

(This is moved here because it makes a good finale.)

For someone who so much loves shouting how stupid I must be, (without providing any evidence to the contrary really)

Have you had enough evidence yet? Or are you thirsty for more? Frankly, if you are, you'll have to go elsewhere. You've proven even to me beyond a reasonable doubt that there is no point in my replying to you any further. To put it bluntly, you suck at debating. Give it up and go help people or play softball or something. Surely you must be better at something you enjoy more than this?

:evil:

"Just call me Lucifer 'cause I'm in need of some restraint. So if you meet me have some courtesy, have some sympathy, and some taste. Use all your well-learned politesse, or I’ll lay your soul to waste." - The Rolling Stones, Sympathy for the Devil

<pre>"Build a man a fire and he's warm for the rest of the evening.
Set a man on fire and he's warm for the rest of his life." - Steve Taylor</pre>

trooper11 · Aug 4, 2004

oh yes i was aware of those two changes to the amd64 code taht amd implimented after the white papers were released, but its not like they were secret. intel deicde to not make adjustments ahead of time to allow for that and just said to hlel wiht it, let ms sort it out. and we all know that whne anything is left to ms either it is messed up horribly or it is just forgotten for years lol. this shoudlnt be an issue, that is my point. there shouldnt have been the ened for some big issue about it that would lead to all this wait time to see any testable systems. intel just doesnt care about x86-64. if they truly did, and wanted to see it suceed for them, then they would have been doing alot of tlaking in the background, certian things would have been ready, at least on pape, and i guess they did. maybe im just thinking too much into this, but i believe intel has the know how and the resources to either have a work around ready to allow for a seamless transition, or have been working closely wiht ms to have a working beta out for the public when they officially launched em64t. but we all know intel doesnt want this to become anymore then a small boost, they dont want it to catch on, that would risk thier itanium line even more. but they had to make some sort of statement to counter amd, so they did this, and they could care les how popular it becomes at this time.

i just dont see intel leaving it up to ms to just get something when they could, surely intel wouldnt be stupid enough to trust ms to get somehting out on time. now that its delayed to Q1 '05, intel just looks more like its copying amd, since it was the company that said it would release the capabilities when the software was there and the market demanded.

64-bit P4 3.2/3.4/3.6Ghz: within a week!!!!

Splendid

Splendid

Splendid

Splendid

Splendid

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Splendid

Distinguished

Distinguished

Distinguished

Distinguished

Splendid

Splendid

Distinguished

Splendid

Distinguished

Distinguished

Distinguished

Splendid

Distinguished

Share this page