Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
If HT doesn't work on "application X", you will slow down everything else on your PC whenever you run it.
Can't you mark a task or program as needing the whole CPU? An obvious (and fixable) failing in the OS software if true.
I'm helping out Keith, it was me.
You are right that you already deleted most of your own post. It was part of a flame thread and made no sense alone, so I nuked it along with the rest of the flame thread.
Matt will restore the posts if he disagrees with my judgement. Perhaps he'll even relieve me of my duties.
I believe that discussion of moderation isn't wanted here, so take it up with Matt or on one of the "how IH is run" boards. You can send me personal mail, but I'm a cheap b...... so I can't reply.
It was probably slowed down because the code size was 10 to 15%
larger and the program used 15 to 30% more data memory to run
because of larger pointers. This increased cache and TLB misses
relative to the 32 bit binary.
I think you are misreading the tables. The code size is given by the "text" entry (confusing but ancient Unix usage) and is actually down by 5-7% relative to the 32 bit version (page 96 of the proceedings pdf). The increase in on-disk executable size is due to the unwind tables, a feature they added for debuggers and some forms of exceptions. In normal usage this data never leaves the hard disk, and it is in any case not directly related to the 64 bit-ness of x86-64 (but rather an improvement they chose to add when they had the chance to define a new ABI).
You are right about the data expanding. This will have a bad effect on some applications, though on average it's still a win to use 64 bit code. If your favourite app is one of the ones affected by data blowup you can run it in 32 bit mode if it doesn't mind the concommitant loss of virtual address space.
These typical code and data expansion figures are well documented
in "Porting GCC to the AMD64 architecture" by Jan Yubicka in the
proceedings of the 2003 gcc Developers Summit.
Funny spelling of Hubicka . The proceedings are on www.gccsummit.org if anyone wants to look. Amongst other things they contain a lot of ideas for further improving x86-64 code.
with his near flawless english
With his near flawless English (US)
With his nearly flawless English (UK)
I promise I'll stop now!
The correct word here would be mettle.
It's a pun. Those clever Aussies.
In AMD’s approach, the transistor’s source and drain region is protected by a silicide layer and the polysilicon gate is completely converted to a nickel silicide (NiSi) metal all the way down to the gate oxide.
Sgolds: About "learnt".
Both are allowed.
http://dictionary.reference.com/search?q=learnt
Is it correct to assume that there´s no real risk for the CC writer in your example, apart from "missing" out on potential gains of the stock he already owns?
No, there is the risk that the stock price will fall. Unless he wants to be left being short naked calls (ie he has sold unexpired calls that he has no stock for) the call seller has to hang on to his shares until the calls expire. That could be painful. He could also buy back the calls and then sell the stock of course.
The premium is fixed at the point the contract is made, ie the seller gets the money up front.
The call (and put) selling strategy works best with a stock that is going nowhere, but where lots of people are convinced that it is going somewhere really soon.
So who is Sanmina?
http://www.bizjournals.com/sanjose/stories/2003/01/06/daily26.html
San Jose's Sanmina-SCI, an electronics manufacturer, says it's landed a contract with IBM to provide a range of additional manufacturing services to IBM in North America and Europe.
As part of this agreement, Sanmina has signed a three-year supply agreement to provide IBM specific manufacturing services.
Sanmina's revenues over the three-year term of the agreement are expected to be in excess of $3.6 billion. Further financial terms were not disclosed.
Under the agreement, IBM will outsource manufacturing of a significant portion of its low and mid-range "eServer xSeries" products and "IntelliStation" workstations and custom configuration of some ThinkPad notebooks for customers in the Americas, Europe the Middle East and Africa to Sanmina.
[...]
http://www.bizjournals.com/sanjose/stories/2003/01/06/daily26.html
Haddock - Are you calling Intel customers fools?
That wasn't me!
Mea culpa, except
#msg-1198009 "Remarkably clueless analyst report:"
That wasn't about anyone here.
#msg-1203633 "Did you even read the reports I linked to"
I would characterise that as a legitimate question. If pieces of evidence are brought to the discussion and people choose to ignore it (rather than state their reasons for not believing it) then we will end up going around in circles even more than we already do.
Apparently this board is no longer about investing in AMD, it's now about making unflattering characterisations of each other, putting labels on each other and general mudslinging:
http://www.investorshub.com/boards/read_msg.asp?message_id=1216413 AMDroid fan boys
http://www.investorshub.com/boards/read_msg.asp?message_id=1216403 smarmy comments by the fanboys
http://www.investorshub.com/boards/read_msg.asp?message_id=1216102 You're the guys with the sour grapes
http://www.investorshub.com/boards/read_msg.asp?message_id=1215373 sore winners
http://www.investorshub.com/boards/read_msg.asp?message_id=1216075 You're the guys with the sour grapes
http://www.investorshub.com/boards/read_msg.asp?message_id=1215855 you [...] gloat
http://www.investorshub.com/boards/read_msg.asp?message_id=1215502 No matter how similar the AMDroids are to a fanatical group with a jihad
http://www.investorshub.com/boards/read_msg.asp?message_id=1215299 Droids hate that
http://www.investorshub.com/boards/read_msg.asp?message_id=1215257 Chipzero & Subguy
http://www.investorshub.com/boards/read_msg.asp?message_id=1215091 AMD faithful could care less about AMD making money
http://www.investorshub.com/boards/read_msg.asp?message_id=1215072 if you only follow AMD making money is an idea long lost
http://www.investorshub.com/boards/read_msg.asp?message_id=1214985 touchy today, aren't we
http://www.investorshub.com/boards/read_msg.asp?message_id=1214973 You should change your sig to Putz
The Opteron will compete as just aother 32 bit X-86 processor and it will compete against the P4 and Xeon processors.
Opteron faces some barriers to entry, but given the vitality of the 32 bit server market I don't think the lack of 64 bit Windows is a significant one.
Since performance and value are competitive and IBM is on board to deliver real (not just cluster) servers I think it's just a matter of time before Opteron volumes ramp.
If AMD can ramp volume there will be a large market for 64 bit software. It won't be necessary to bribe any software vendors to do ports, their customers will demand it of them, and the size of the potential market will make it attractive.
Just like presumably Cadence's customers did, which I guess is why Cadence are making 64 bit software to go with the 64 bit OS software that is already available.
As for your 40 bit jibe, I doubt AMD customers have serious trouble with the 1 Terabyte physical RAM limit. It's the 33rd bit that's the most important innovation. After that the 34th. By this measure the Itanium isn't a true 64 bit CPU either. Who cares?
Great, we now have the smart alleck one-liner attacks that took the SI mod thread down the tubes
God forbid that anyone should post smart alec one-liners on this thread!
http://www.investorshub.com/boards/read_msg.asp?message_id=1213589
http://www.investorshub.com/boards/read_msg.asp?message_id=1212809
http://www.investorshub.com/boards/read_msg.asp?message_id=1177086
http://www.investorshub.com/boards/read_msg.asp?message_id=1162553
Haddock, I agree that if you look hard enough, you can find very good deals on low speed Athlon systems.
I didn't look hard, it was the first page I checked.
No wonder they end up with a ~$65 ASP after selling Athlon XP for $hundreds.
ASPs must be rubbish (they didn't dare say them at the CC, did they?). But this particular discussion was from the point of view of the consumer.
Otherwise, if AMD sold Athlon for the price they have listed on their webpage, I don't see Celeron as much worse.
From the point of view of a consumer the prices on AMD's webpage are (sadly for the investor) irrelevant.
Athlon performance tends to trend towards Celeron performance when given the same low end memory and chipset
Do you think so? The benchmarked low end Athlons and Celerons were all using DDR-266 RAM, and this is the same RAM that was in the systems who's prices I linked to. Obviously a shop like that will cut corners, but I see no reason to think they cut corners more with one CPU than the other within the same PC model name. Both systems use a VIA chipset btw.
http://www.ecsusa.com/products/k7vmm_plus.html
http://www.ecsusa.com/products/p4vmm2.html
Sun's rising in Beaverton - time to get some sleep!
http://www.worldtime.com/cgi-bin/wt.cgi
I think it's a forlorn conclusion to say that an increase in GMs means that Pentium 4 is losing competitiveness (at least, that seems to be the conclusion aiming to be made here).
Not at all, I was merely reporting that AMD's GMs seem to have recovered slightly, plus some commentary on Chipguy's suggestion that the quality of the P4 core design could be judged from Intel's GMs.
The Opteron sells as a 32 bit machine in fact with the capability in the future of employing 40 bit physical addressing. The Xeon processors are 32 bit machines with 36 bit memory addressing that has been supported in OS and application software for several years.
Huh? Opteron supports 36 bit addressing in exactly the same way as Xeon if that's what the customer wants. And you 'forgot' the capability of doing 48 bit virtual addressing and the fact that you can use those features (plus 40 bit PAE) right now if you use Linux.
>> Who here would recommend a Celeron box to a close friend?
>
> I certainly would, as long as performance were not
> a requirement. I would also recommend an Athlon/nForce
> platform, if the price was right. Both platforms have
> their advantages, depending on the requirements.
I think you'll find the price favours the Athlon XP. If you look at Celeron systems and Athlon XP systems with the same "name" you'll find that the Celeron system is a little more expensive but the performance is much worse.
Here are the prices at my local cut-price mail order company:
http://www.compumail.dk/nypc/standard.html
Here are some price-performance charts from an Ace's article that I linked to a while ago. They are a little out of date, but I don't think the picture in the low end will change much until Celeron gets Hyperthreading:
http://www.arbat.com/erik/mpeg.png
http://www.arbat.com/erik/pp.png
Bang/buck increases as you go north-west, falls as you go south-east. The new HT-enabled P4s that have arrived since the charts were made will change things in Intel's favour in the north-east corner, but the south side will still have a lot of poor-value Celerons.
Hi all, there's a CC summary on http://www.amdzone.com/articleview.cfm?ArticleID=1310 (thx to the Inq for the linq).
Chipguy:
AMD margin (from SEC filings)
2000 46% (P4 intro'd Nov, 2000)
2001 33%
2002 22%
2003q1 31%
2003q2 34%
So wow!, what a "performance" by the P4!
I agree the P4 is a great product (though gross margin is at best a rather indirect way to prove it). Lucky for AMD that the P4 doesn't have an onchip memory controller and 64 bits.
As far a ownership of AMD shares maybe everyone could come clean and post how many they own
I think in general people are likely to not want to post absolute numbers, but portfolio percentages are more reasonable.
Right now I have 0% of my portfolio in AMD shares (but I'm not going to reveal the absolute numbers . I'm waiting for evidence that AMD has their clock speed problems on SOI solved, and also I think the market in general is overdue for an adjustment. In the (recent) past I have had >50% in AMD and have paid dearly for it.
How about some OS support - what OS runs on an Opteron that does not run on an Itanium?
NetBSD
I don't know of any chipset that allows PCI devices to use the GART, so if AMD intends on making the GART into a more generic feature, they're completely on their own here.
Apparently the HP ZX1 chipset has a generalised IOMMU that takes over the function of a GART and also does something similar for PCI cards.
You didn't answer whether 32-bit only PCI cards can access high memory on an Intel Itanium chipset. Are you forced to use bounce buffers (where the data is temporarily copied to or from the 4Gbyte area where the PCI card can see it) or can you use an IOMMU to give the PCI card access to high memory. Or are you forced to use 64-bit aware PCI cards (in the minority I gather).
These theories you guys are posing don't make any sense.
I'm not making this stuff up. Here's the view from the guy who actually wrote the Linux drivers. I'm guessing he has a pretty clear view of at least the visible aspects of what AMD implemented.
http://groups.google.dk/groups?selm=4yZt.6DY.19%40gated-at.bofh.it
"K8 doesn't have a real IOMMU. Instead it extended the AGP aperture to work for PCI devices too."
In the same thread, H. P. Anvin writes:
[The AMD64 IOMMU window is] a window (in the form of a BAR - base and mask) within which IOMMU mapping always takes place. Outside the window everything is bypass.
This applies to all x86-64 machines and some i386 machines, in
particular those i386 chipsets with "full GART" support as opposed to "AGP only GART" (my terminology.)
Andi likes to say this isn't a real IOMMU (mostly because it doesn't solve the legacy region problem), but I disagree with that view. It still would be nicer if it covered more address space, though.
Unfortunately he doesn't say which i386 (he means x86) machines have a 'full GART'.
http://www.cs.helsinki.fi/linux/linux-kernel/2001-20/0249.html
Did Intel put figures on the Itanium business at the CC?
Harddock,
It's Haddock, as in Tintin
I may be wrong, but I think you just described the model of vector processors rather than MPP systems
No I described Red Storm. See page 15 of www.cs.sandia.gov/presentations/ 2003/HPC%20User%20Forum.ppt
I wonder how well it will work if they mix 146 and 148 and whatever will be next together?
All the nodes will apparently work at the same speed as the slowest one, as they all wait for results of the last step before they start the next. At least that's how I interpret the stuff on why they aren't using a Unix-like OS on the compute nodes. (If one CPU takes a 5us timeout to do a background task then they all have to take a 5us timeout. Do this at all often at random times on 10000 CPUs and you hardly get anything done at all.)
It's equivalent to if some cpu's are doing some additional background calculations while some others are not.
They don't run additional background calculations on the compute nodes.
I don't think it's technically possible to design a A64 chipset that does not support the 64 bit addressing.
That was my point. By putting the IOMMU/GART in the CPU, AMD made sure of that.
Haddock, I don't nesessary see that being aquired means the company is in trouble
Nor me, but the rumour said they were for sale, not that they were being aquired...
Interesting theory on Socket939
http://www.aceshardware.com/forum?read=105024054
Red Storm uses Opteron 148
Presumably that's 1 HT link, 1Mbyte cache, 2.2GHz.
http://babelfish.altavista.com/babelfish/urltrurl?url=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2F2....
Thanks to mas on Ace's.
(Edit: Of course I'm too polite to point out that this means I was right in dismissing as rubbish all talk of using 2xx or 8xx Opterons to make cache-coherent multi-CPU nodes.)
Zeev on Intel:
Does INTC correct their numbers post facto? When I go to Yahoo Financials to the balance sheet I find the last quarter receivable in excess of $4 B but in the current report for the same first Q 2003 it is only some $2.9 B, there is also a difference of $100 MM between the Yahoo financials cash flow statement on depreciation for the same quarter...strange. Of course, if INTC had to amortize the $4 B in goodwill (instead of the "voluntary" $84 MM in amortization), the picture is not as rosy. No note anywhere in the financial press that this quarter was not as good as the last one in net revenues despite (about $20 MM short of last Q) despite the fact that the top line was about $65 MM higher.... Well, not a bad report after all.
http://www.investorshub.com/boards/read_msg.asp?message_id=1208238
So is Banias pulling its weight? Did they reveal ASPs? Anyone want to guess?
and a very optimistic outlook
"No sign of the corporate replacement cycle". It could have been better.
I still think we are in a bear market rally, to be honest. I can't buy all this "rising unemployment is bullish" stuff when the consumer has been driving the economy and the comments above indicate that the corporations aren't about to take over that role if the consumer pulls in his debt-building horns in the face of employment uncertainty.
But tomorrow will be a good day for the markets. It better. Zeev is talking about a "high risk area" for the stock market http://www.investorshub.com/boards/read_msg.asp?message_id=1201260
I hope Intel's good quarter benefits SGI's stock price .
Maybe Intel ought to design another faulty MTH, just to relive those good ole days
These days they are content to just put the memory controller on the wrong chip.
That's 5-10% of AMD's market share, right? Of course it's easier for Intel to say what their own sales were than to say what total sales were (and thus market share).
Interesting that Asia did so well for Intel. That's where 'SARS' did so much damage to AMD's sales. Since the Asians are known to like portable machines perhaps it's a reflection that mobile Athlon isn't doing to well (and Banias is).
AGP is logically a PCI bus as far as I understand. Electrically it is limited to a single device in order to allow higher speed connections.
So it doesn't seem a terribly deep distinction.
Systems with multiple AGP buses aren't that hard to design.
Not if you are the chipset designer, but can you do it with existing chipsets? I don't think the market is necessarily big enough to justify a completely new chipset.
The only thing HyperTransport brings to the table is a standard interface to hook up two identical AGP tunnels, which saves on development costs at the expense of, say, performance.
It's not that difficult to think of a way to do it without sacrificing performance. For example a dual machine with AGP bridges off both CPUs. Or a single CPU system with a 2-port Opteron (244 or similar).
You are talking about TLBs, which are separate from GART entries. Both do address translation, but at different levels (one is instruction level, other is I/O level).
One is address translation for the CPU, the other is address translation for the IO device. In any case if you have more than one CPU you need to keep TLB changes coordinated so both CPUs have the same view of the world - that means the infrastructure is there already and can be reused for the GART. So it's no big deal for the OS writer, and since GART changes are likely rare I think it's no big deal for performance either.
The TLB is in the core of the CPU, where the address generation needs to take place. Would you move the TLB (or in general, the address translation) from the CPU execution units to the memory controller? I wouldn't. And neither would I move the GART from the AGP controller to the memory controller.
There are lots of good reasons to keep the TLBs close to the CPU. Issues of cache coherency, virtual-physical address aliasing, frequent task switches etc. mean that you would lose a lot of performance otherwise. In the case of the GART these issues don't pertain, and the changes to the memory mapping are made by the CPU, not the AGP chip. In the case of PCI, Andi Kleen reports that it is faster to remap memory to make data contiguous than to let the chip on the PCI card do scatter-gather.
We were talking about PCI bridges in chipsets, not PCI cards.
It was merely an example of the sorts of quick-and-dirty cost cutting measures that people will take to save a few cents. Putting the GART in the CPU means AMD takes control of it and means noone else can mess it up for them. And there seem to be no concrete disadvantages that I can see - on the contrary, performance is improved.
Intel's 460GX chipset for Merced located the GART on the AGP bridge, which is separate from the north bridge. The 870 chipset for McKinley and Madison doesn't support AGP, but if it did, the GART would have also been located on the I/O bridge where AGP is located.
What about non-64-bit aware PCI cards? They have their own MMU on the north bridge?
Of course it would be silly to put a GART on the CPU with the Itanium II system architecture, since that would mean addresses would have to go AGPdevice->NorthBridge->CPU->Northbridge->Memory to be translated. In the case of the Opteron the addresses go AGPdevice->AGPbridge->CPU->Memory so the exact location of the translation virtual->physical isn't so important.
Please forgive this minor correction but AGP is a Port, not a buss.
So much more reason to want two of them
Tenchu, perhaps the reason you have never seen a system with two AGP busses is because it is so difficult to do with current chipsets. With a Hypertransport-based chipset it is simple, and I expect to see it for Opteron workstations. Why should people who need more than one graphics card have to put one of them on PCI?
Wouldn't you agree that having one GART on the AGP makes more sense than having two GARTs, one on each CPU?
There are lots of situations where the CPUs need to coordinate their virtual address mapping (I seem to recall Linux doing inter-CPU interrupts to inform of address map changes where two threads on separate CPUs both have the same (changing) address space. Given this, I guess it's not much trouble to include GART updates in that mechanism.
As for the 64-bit question, if the bridge builder was "too lazy to make sure 64-bits worked right," then the PCI devices below it would not be able to access any address above 4G
I think normally a PCI bridge does no address translation at all, leaving it to the card drivers to handle virtual-physical translations. Since most PCI cards can't handle 64 bit addresses the OS needs bounce buffers etc.
If you have a mechanism for PCI it's probably best to include AGP in that, since they are so similar in many respects. Keep it simple.
no one in their right mind would ever design an Athlon 64 chipset that didn't support 64-bit addressing.
People do PCI cards that can only address 28 bits of memory in order to save a few cents, so I think you shouldn't underestimate the corners people will cut. Take a look at the comments in Linux drivers and you will see that if a corner can be cut then someone cut it.
How does all this work on an Itanium system?
There's an obvious reason to put the GART on the CPU: It simplifies the driver situation massively. Instead of n AGP bridges and m PCI bridges (or worse, x PCI devices as seems to be common on non-Hammer systems) doing the work you have 1 CPU to write a driver for. Also, you can make sure that it is 64 bit clean, even if the devices know nothing of 64 bits and/or the bridge builder was too lazy to make sure 64 bits worked right.
Re. GART/AGP support in Opteron
Andi Kleen has now explained in the thread: "Essentially on Athlon64 systems the AGP bridge is a quite dumb bridge that just converts HyperTransport to AGP, most of the complicated parts of AGP (GART memory remapping etc.) have moved into the CPU."