AMD demo's native quad-core

[LstBrunnenG]

In fact I was actually anti-Intel, and anti-x86 altogether (but back in the day, those were equivalent)... the only CPU brand I've ever been fan of is Motorola.
I could care less about either Intel or AMD, I still think x86 is a monstrosity, no matter who makes it... and I've bought either brand over the years, depending on which monstrosity gave best value-for-money at the time.

Just curious, why do you feel X86 is a monstrosity?

Oh and don't worry Visaris, this is in fact on topic because AMD's quad core, whether it be faster or slower than current AMD or Intel products, will use X86.

 

[Scali2]

Just curious, why do you feel X86 is a monstrosity?

I like to describe it as "Flying a Space Shuttle with a pair of tweezers".
The backend of current x86 processors is really powerful, but because the x86 instructionset is so poor, it's impossible to efficiently use all the resources of the backend.
With more registers, more operands and a streamlined instructionset, you could make the CPU itself leaner (smaller dies mean lower prices and/or higher performance through higher clockspeeds or larger caches) and at the same time increase the IPC because you can unlock the full potential of the backend.
Getting back to Motorola, which I mentioned... In the early days, Motorola offered a nicer instructionset and more registers on the 68000, which translated in higher IPC, and easier programming (back then it was still mostly assembly, these days it won't matter anymore, unless you're a compiler writer). Later they repeated this with the PowerPC (although this architecture was actually borrowed from IBM... they did add AltiVec though, which was an excellent SIMD instructionset, way ahead of 3dnow!, MMX and SSE).

In the end PowerPC started to suffer the same problems as x86 though, albeit to lesser extremes. But partly PowerPC lost from x86 because of the sheer size of the x86 market, and Intel... Motorola just couldn't afford to pump in enough R&D... it was pretty much only for Apple. They decided to call it quits after the G4.

In short, the Motorola CPUs were just leaner and meaner... more modern in a way. I think it's a shame that there are no alternatives anymore in the desktop world... even Apple uses x86 now. End of an era... Brute force won over elegance in the end.
But I'm still convinced that you could develop a much more efficient architecture than the x86... there always were such architectures, and it's more economics of scale than technical reasons that x86 succeeded in the end.

 

[visaris]

Would you care to explain why you do not like it?

I already did, please read more carefully.

My problem with you is not your opinions, but your outright lies. At the time of your post, you had not explained why you don't like the L3 cache, and your claim that you did, is nothing short of a lie:

K8L basically takes 4 cores with non-shared L1 and L2-cache, just like the current K8, and then patches it with some shared L3-cache. Hardly what I'd call a good design.

Why?

Shared L3-cache is questionable... and considered poor when the competition will offer shared L2-cache.

Why?

(rumour is 512 kb L2 per core and 2 mb shared L3 cache, which is basically just a 'shadow memory' of what is in the L2 caches, so effectively no extra cache size, just a buffer to synchronize L2-caches more efficiently).

This is the closest you come to giving a reason, but even it is false. The L3 is not just a shadow of the L2. The only way what you say could possibly be true is if AMD used a totally inclusive cache design, which they did not.

This shouldn't be an issue if the cache size is equal to the total of independent per-core caches [. . .]

This comment makes no sense at all. I'm talking about one emtreme with all shared cache. You talk about "independent per-core caches" and thus, are not even making a remark on the scenario I present.

[. . .] and the set-associativity of the caches is good. Then you are in effect dynamically allocating the cachelines on demand of the cores. Tests with my own software concluded that Core2 Duo does an excellent job of this, so I expect that Intel will also be able to come up with decent performance for a shared cache between 4 cores.

Wow. I asked if you could explain why you don't like a shared level 3 without talking about Intel. You managed to fail miserably. This whole paragraph says nothing about AMD's cache hierarchy, and only serves to justify why you like Intel's shared-only cache design. Set-associativity does help, but does not completely solve the problem. Just as larger caches help, but don't solve the problem. Also, I'll call your bluff, show me your code; I doubt you have anything that can demonstrate your claim.

In no situation will it perform as well as shared L2-cache will.

Lol. Wow. This is a direct claim that cache-thrashing is not a real effect. I guess Intel just doesn't have to play by the rules. They are able to escape reality...

I already gave the answer, without having to compare to Intel. Shared L2-cache is one level higher in the hierachy, meaning less latency, more speed, more performance.

And cores fighting over the cache lines...

Other than that, I already said the cache is very small, so it can only be used to 'mirror' the L2-caches, it cannot provide additional caching.

Again, false. Only with a 100% inclusive cache will the L3 not provide much additional caching. With exclusive support, the cache adds capacity. You are totally wrong about the L3, that might be why you don't like it.

 

[Scali2]

My problem with you is not your opinions, but your outright lies. At the time of your post, you had not explained why you don't like the L3 cache, and your claim that you did, is nothing short of a lie:

Because the answers to your questions are so trivial, it hurts.
In short: L2 is faster than L3.

This is the closest you come to giving a reason, but even it is false. The L3 is not just a shadow of the L2. The only way what you say could possibly be true is if AMD used a totally inclusive cache design, which they did not.

If it's not totally exclusive (which it isn't), the rest is moot.

This comment makes no sense at all. I'm talking about one emtreme with all shared cache. You talk about "independent per-core caches" and thus, are not even making a remark on the scenario I present.

It should make sense to anyone who understands what he's talking about.
If you have 4 cores, with each 1 mb of cache, you will need 4 mb of shared cache, to be able to distribute 1 mb of cache to each core, via set-associative caching. Savvy?

Also, I'll call your bluff, show me your code; I doubt you have anything that can demonstrate your claim.

http://scali.eu.org/~bohemiq/FireNew.rar

Lol. Wow. This is a direct claim that cache-thrashing is not a real effect. I guess Intel just doesn't have to play by the rules. They are able to escape reality...

Nice that you ignore the above paragraph already. As I said, I tested extensively, and found that indeed Intel doesn't suffer from cache-thrashing... Scaling from 1 to 2 threads gave similar results when compared to Pentium D and X2.
Perhaps you just need to face reality and admit that Intel has a very good implementation of shared L2-cache.

And cores fighting over the cache lines...

Perhaps you should do some practical tests like me, and then draw your conclusions.

Again, false. Only with a 100% inclusive cache will the L3 not provide much additional caching. With exclusive support, the cache adds capacity. You are totally wrong about the L3, that might be why you don't like it.

We'll see when we can actually benchmark the processors. I'm rarely wrong on this sort of thing.

 

[visaris]

$ unrar e FireNew.rar

UNRAR 3.60 freeware      Copyright (c) 1993-2006 Alexander Roshal

FireNew.rar is not RAR archive
No files to extract

I'll try it on a windows box when I have a chance later.

 

[Scali2]

Then you'll probably need this: http://go.microsoft.com/fwlink/?linkid=65127&clcid=0x409
Before you go nagging that you can't run it etc...

 

[visaris]

Scali, I have to say that no matter how much I disagree with you, you do have a good general understanding of the subject. I enjoy arguing the issues with you more than most others because of this (even if I wish you would stay on topic more).

In all the arguing (fun even if frustrating) I've lost track of my main point. Again, my point isn't about AMD vs. Intel cache structure, it's about K8 vs Barcelona cache structure. One of the reason's I don't like Intel being brought up here is precisely because it distracts from a detailed discussion of one or the other and invariably turns into a shallow (as in not detailed) fight over which has the better design.

The point is that Barcelona's cache is clearly faster than K8's. This is easy to see as many K8's have 512K independent L2 per core and no L3. This means that any cache misses go to main mem. Barcelona will have the same 512K cache in addition to the 2MB L3, where a cache hit will much faster than main mem. Considering the L3 cache latency will be insignificant compared to that of main memory anyways, the only way adding a L3 will make the chip slower is if it has an abismal hit rate: it holds the exact same data as L2. The fact that the cache supports exclusive operation as well as AMD's history of using exclusive caches supports the idea that the L3 will provide additional cache space and will have a reasonable hit rate, thus improving performance.

I know you like the AMD and Intel comparisons, so let's throw one in to keep you happy: I see your point that AMD's shared L3 is slower than Intel's shared L2. However, this fact totally ignores the speed of AMD's L2 and the issue of hit rate. In general, the simpler the cache, the faster it is. AMD's independent L2 is faster than Intel's shared L2. If Intel has a high hit rate (~95%) on their slow, larger, shared L2, and AMD has a lower hit rate (~90%) on their small, faster, independent L2, AMD will probably have a lower average cache latency than Intel, even with an additional slower L3. In a sense, Intel's single large shared cache is slowing down all L2 hits, while AMD's multi-level approach will not slow down any L2 access, only main memory latency, which is already horribly slow and takes a very small hit percentage-wise.

 

[Scali2]

Scali, I have to say that no matter how much I disagree with you, you do have a good general understanding of the subject. I enjoy arguing the issues with you more than most others because of this (even if I wish you would stay on topic more).

I don't enjoy arguing with you, because you often overlook things in my post, or simply ignore them altogether, and you often resort to personal jabs.

I know you like the AMD and Intel comparisons, so let's throw one in to keep you happy: I see your point that AMD's shared L3 is slower than Intel's shared L2. However, this fact totally ignores the speed of AMD's L2 and the issue of hit rate. In general, the simpler the cache, the faster it is. AMD's independent L2 is faster than Intel's shared L2.

If only that were true. Just look up results of Sandra or Everest cache bandwidth and latency benchmarks (like here: http://tweakers.net/reviews/654/3), and you'll see that AMD's caches aren't faster than Intels at all.
In fact, the Core2 has nearly twice the L2-bandwidth, and close to three times(!!) the L1-bandwidth of the Athlon64 when you are copying from one place to another (apparently the Athlon's cache access is half-duplex, may have something to do with the fact that it's exclusive).
Latency-wise, Intel and AMD are pretty well-matched aswell.
Other than that, the associativity of AMD's caches is rather poor... so the cache isn't all that effective either... which is an extra big issue considering the small size.

Again, I urge you to do more practical testing and comparisons, because you have apparently based your whole argument on incorrect assumptions about AMD's cache. Apparently you underestimate Intel... Caching is perhaps Intel's strongest point, and perhaps the main reason why Core2 performs as well as it does (the rest of the CPU isn't all that different from an Athlon, really). I know it's the reason why my program runs extremely well on Core2 and Pentium D... it fits entirely in the cache... on 512 kb Athlons it runs poorly... 1 mb Athlons are decent.

 

[visaris]

I don't enjoy arguing with you, because you often overlook things in my post, or simply ignore them altogether, and you often resort to personal jabs.

Lol, I guess you can dish them but can't take them ("It's people like you...", etc, etc). Typical. Anyways, you should be more explicit and say exactly what you mean, rather than expecting others to fill in the holes. Writing explicitly and clearly will reduce the number of times people "overlook" things.

In fact, the Core2 has nearly twice the L2-bandwidth, and close to three times(!!) the L1-bandwidth of the Athlon64 when you are copying from one place to another (apparently the Athlon's cache access is half-duplex, may have something to do with the fact that it's exclusive).

That is true. Intel's caches have great bandwidth. However, I was referring to latency (though, I'm sure you'll find a way to tell me that AMD doubling the L1 cache bandwidth in Barcelona will make it slower).

Latency-wise, Intel and AMD are pretty well-matched aswell.

Heh, and you link to a site with latencies in absolute time, not cycle time. Way to throw in an extra variable, clockspeed, which is irrelevant for the discussion of efficient cache hierarchies. L2 cache latency: Dothan - 10 cycles | Core 2 - 14 cycles | K7 - 11 cycles | K8 - 12 cycles. Look at what happened with Dothan vs. Core 2. The simple independant caches in Dothan were much faster than the slower shared cache in Core 2. Just as AMD's cache is faster than Core2's. And that is shared between 2 cores. The cache may slow down a bit in Intel's shared L2 native quad-cores because an additional two cores must be supported. I don't know if this will introduce much, but I would not be surprised to see at least an additional cycle added.

Again, I urge you to do more practical testing and comparisons, because you have apparently based your whole argument on incorrect assumptions about AMD's cache.

You use data that introduces irrelevant variables (clockspeed) in your comparison of cache hierarchies. Your data is causing you to draw incorrect conclusions.

Caching is perhaps Intel's strongest point, and perhaps the main reason why Core2 performs as well as it does (the rest of the CPU isn't all that different from an Athlon, really).

Intel is known for good caches and especially large caches. They have a smaller SRAM size to boot. That doesn't mean no one else in the world is able to come up with something that works better. I think you underestimate the boost AMD's L3 will be able to provide their architecture.

I know it's the reason why my program runs extremely well on Core2 and Pentium D... it fits entirely in the cache... on 512 kb Athlons it runs poorly... 1 mb Athlons are decent.

My software does not perform as well on core, though I can't say I'm at all surprised. Most simulations are heavily threaded, optimized for NUMA, and usually use 6-8GB ram. The multiple independent memory controllers really help out. Hmm, you like Intel because you want to do small problems fast, and I like AMD because I like to do large problems fast. Like I always say, buy the product that fits your personal needs the best.

 

[Kil4Thril]

Thanks guys. I need an Aleve now. Good information, just too damned much of it.

 

[Scali2]

Lol, I guess you can dish them but can't take them ("It's people like you...", etc, etc). Typical. Anyways, you should be more explicit and say exactly what you mean, rather than expecting others to fill in the holes. Writing explicitly and clearly will reduce the number of times people "overlook" things.

Sorry I overestimated you.

Heh, and you link to a site with latencies in absolute time, not cycle time. Way to throw in an extra variable, clockspeed, which is irrelevant for the discussion of efficient cache hierarchies.

It's not actually, since Core2 and Athlon generally don't run at the same clockspeeds.
Absolute performance is all we care about. Relative performance is only interesting when you run at the same clockspeeds.
Nevertheless, even at the same clockspeeds, Core2 and Athlon are quite closely matched... Which is a great achievement, considering that Intel's L2-cache is way larger, and shared aswell.
The way you try to twist these numbers into AMD's advantage is sickening.
The point is simple... Intel's L2-cache is about as fast as AMD's non-shared L2-cache.
Adding shared L3-cache will in no way make AMD's performance equal to Intels. Or did you forget what you were arguing?

I think you underestimate the boost AMD's L3 will be able to provide their architecture.

I'm not underestimating anything. I'm just being sceptic, as it would be a miracle for AMD to create an L3-cache that performs better as well as their current L2-cache.
It's so incredibly likely to happen that I don't see how you could possibly assume it will.

My software does not perform as well on core, though I can't say I'm at all surprised. Most simulations are heavily threaded, optimized for NUMA, and usually use 6-8GB ram. The multiple independent memory controllers really help out. Hmm, you like Intel because you want to do small problems fast, and I like AMD because I like to do large problems fast. Like I always say, buy the product that fits your personal needs the best.

I like Intel because it's the best in every possible situation at this moment.
My last CPU was an AMD, and ironically I actually wrote this routine on that CPU.
And small problems? You must be joking... This is realtime volume visualization, with the MarchingCubes algorithm. Pretty heavy stuff.
The fire-test is just small, but using an MRI-scan of a human body changes that immediately, ofcourse.
And no, an Athlon or Opteron won't suddenly be faster.

So let's recap:
First you claim that larger caches are slower (higher latency), and that a shared cache is slower than non-shared... Granted, with ceteris-paribus comparisons, that would be true.
Then go to conclude that AMD's cache must be much faster because it's smaller and non-shared.
So I present benchmarks that show that Intel's cache actually delivers more bandwidth (a LOT more in some situations), and that still the latencies are pretty close to AMD's, despite being much larger and shared.
Then you go cry about the fact that the clockspeeds are different (yes, indeed, there is no 2.8 GHz Core2 to compare to the Athlon64... so what?). Which is irrelevant, it's clear to see that the caches are in the same ballpark, latency-wise, even if you'd correct for the small clockspeed-differences.
But then you claim that AMD's shared L3-cache will fix this... How on earth is that possible?
Even if we assume that AMD's shared L3-cache will be as fast as Intel's shared L2-cache (which it probably won't... remember that this is already Intel's second generation of shared caches, they have a lot of experience... AMD is only just beginning... besides, if the cache was that good, AMD wouldn't bother with L2-caches at all, because the shared cache would be efficient enough to be used as L2)...
Then still it's L3-cache, not L2-cache, so still there'd be more latency and overhead... You'd still have to go through the L2-cache, and you'd have to sync that via the L3-cache, so you lose bandwidth there too.
And then still it'd only be 2 mb for 4 cores, where Intel is using 4 mb for 2 cores... So it's a factor 4 smaller.
Apart from that, to use such L3-cache efficiently, the L2-cache would have to be made much faster, which I don't see happening.
So really, it's extremely unlikely that AMD's L3-cache will bring its caching back on par with Intel.

I'm done talking to you. Either you are nowhere near my level of knowledge, and simply don't understand things, or you are so blinded by AMD, that you don't want to listen to reason.
I'd also like to see some of your code. See what kind of stuff you write.

 

[visaris]

It's not actually, since Core2 and Athlon generally don't run at the same clockspeeds. Absolute performance is all we care about.

If absolute performance is all you care about, take your critical app, run it on the hardware in question and buy the fastest one. This way, you don't have to think about much, because it is clear you really don't have an academic attitude at all. You don't care to understand the advantages of different designs and you are unable or unwilling to isolate and compare units of the CPU in a abstract way. You always come back to: intel is faster! intel is faster! It amazes me.

If you are unable or unwilling to do an analysis with latencies described in some form of relative time (preferably cycles), you will be unable to correctly describe how the cache will scale with clockspeed, an important factor in estimating the performance of future processors. No wonder you don't think Barcelona will perform well.

I'm done talking to you. Either you are nowhere near my level of knowledge, and simply don't understand things, or you are so blinded by AMD, that you don't want to listen to reason.

I show you that AMD has a faster cache and your response is that it doesn't matter because intel has a clockspeed advantage... It's funny because your own data (http://tweakers.net/reviews/654/3) shows that AMD's L2 is faster, though, only slightly. You are so blinded by Intel, you are unwilling to admit that any one component of AMD's chips are better than that of Intel. Intel has the performance crown, that's great. Let's break down the chips, see which company has the better design for the various functional units, because it will increase our understanding (and possibly that of others). Intel will take the win on some and AMD will take the win on some designs. I still don't see why you are unable to think about it, and simply resort to the "Haha, Intel's final product is better, so that means that Intel's chips are better than AMD's in every possible way." Way to take the discussion off the topic of the cache and bring it full circle to your inevitable "intel is better" conclusion.

I'd also like to see some of your code. See what kind of stuff you write.

I write evolutionary simulations, specifically in the area of speciation. I'll provide two of my slightly older NSF/NIH projects. This will only be up for a few days (ongoing research I don't want to spread around), so grab it while you can. For each, I will provide a paper (published by PNAS) describing the model as well as the code.

niche:
http://neko.bio.utk.edu/~avose/code/ar.pdf
http://neko.bio.utk.edu/~avose/code/niche/

tmm:
http://neko.bio.utk.edu/~avose/code/mi.pdf
http://neko.bio.utk.edu/~avose/code/tmm/

 

[savantu]

That is true. Intel's caches have great bandwidth. However, I was referring to latency (though, I'm sure you'll find a way to tell me that AMD doubling the L1 cache bandwidth in Barcelona will make it slower).

Hi Baghdad Bob.

If you haven't noticed , Intel's L2 has the same latency as K8 , while being shared ( arbitration mechanisms cause more latency , Dothan vs. Yonah ), far greater BW and it is 4 times larger.

With all this , you claim AMD's L2 is faster ?!

You need to be struck by the clue bat.

Heh, and you link to a site with latencies in absolute time, not cycle time. Way to throw in an extra variable, clockspeed, which is irrelevant for the discussion of efficient cache hierarchies. L2 cache latency: Dothan - 10 cycles | Core 2 - 14 cycles | K7 - 11 cycles | K8 - 12 cycles. Look at what happened with Dothan vs. Core 2. The simple independant caches in Dothan were much faster than the slower shared cache in Core 2. Just as AMD's cache is faster than Core2's. And that is shared between 2 cores. The cache may slow down a bit in Intel's shared L2 native quad-cores because an additional two cores must be supported. I don't know if this will introduce much, but I would not be surprised to see at least an additional cycle added.

What about 4 extra cycles due to arbitration mechanism?

K8 might have a 12 cycle acces time , but it's at the top of its frequency shmoo.
Core/Conroe OTOH scale beatifully in frequency and not only are they as fast in absolute time , but once you up the frequency the advantage increases dramatically.

And your very shallow reasoning stops you from seeing the obvious ( did I mention the clue bat ? ) : it is a shared cache.Mind telling us how much it costs in cycles and absolute time for a K8 core to write/copy/modify a L2 line in the other's core cache ?

For Core/Conroe I'll give you a hint : it is still 14 cycles.

 

[Scali2]

And that's why I don't talk to you anymore.
I will respond to one thing though, because this is simply not true:

I show you that AMD has a faster cache and your response is that it doesn't matter because intel has a clockspeed advantage... It's funny because your own data (http://tweakers.net/reviews/654/3) shows that AMD's L2 is faster, though, only slightly.

Excuse me, but 'faster' is too vague a term.
If you mean the bandwidth, then obviously Intel is faster.
If you focus only on latencies (why? even in academic terms there's more to cache performance than just latencies), then I never claimed Intel was faster.
I said this:

Latency-wise, Intel and AMD are pretty well-matched aswell.

Which they are, the difference is marginal, albeit in AMD's advantage.
But, academically speaking, Intel has the advantage in bandwidth, cache-size, shared-cache and higher clockspeed.
So while I never argued that AMD has lower latencies (I have no problem admitting that some parts of AMD's architecture are superior, and in fact I have used AMD CPUs extensively over the past few years, for that very reason), it should be clear that, academically speaking, the margin is far too small to overcome all the other points, and get better overall performance.

Surely an academic mind such as yourself can see the objective truth that for every cache design you have make compromises, as cache features are usually give-and-take, and Intel has the better balance of factors in its design.

 

[savantu]

Surely an academic mind such as yourself can see the objective truth that for every cache design you have make compromises, as cache features are usually give-and-take, and Intel has the better balance of factors in its design.

Exactly.Not to mention the extreme difficulties involved in having a cache that large , with exceptional BW , sharing mechanism , good scalability and keeping latency that low.It is simply a tour de force , cache design and execution at its finest.

 

[visaris]

If you are done talking to me, great. Go post in some other thread and stop spreading your FUD here. Go make a thread that says "Intel's cache is better than AMD's in every way." I won't even bother posting in it, because I simply don't care. However, this is a thread about AMD's quad-core. Discussions on Intel, Power, Cell, etc, are not appropriate topics here. This is the last post I'm going to make in this thread that even mentions Intel, I'm done.

I have never argued that AMD is better at making caches. I even gave numbers showing Dothan's independent cache a whole 2 cycles faster than AMD's. The point is that while Intel has better caches, AMD has a superior cache hierarchy. Intel has many advantages with their cache, and it is a good design. However, as you yourself say, there are always trade offs. If Intel were to merge their good cache design with a more appropriate hierarchy, Intel would have an even better cache. It's amazing that you can't admit that, and simply bash it with hardly any logical support (almost as if you don't like it simply because AMD is doing it...).

 

[visaris]

A little more information on the quad-core demo:

http://www.theinquirer.net/default.aspx?article=36131

 

[Scali2]

The point is that while Intel has better caches, AMD has a superior cache hierarchy. Intel has many advantages with their cache, and it is a good design. However, as you yourself say, there are always trade offs. If Intel were to merge their good cache design with a more appropriate hierarchy, Intel would have an even better cache. It's amazing that you can't admit that.

I don't have to admit that because I simply do not agree.
What do you mean with cache hierarchy anyway? You mean that Intel should use a shared L3 cache instead of L2, and go back to non-shared L2-cache?
Well, obviously I don't agree there, I've even shown you my software which proves that the shared L2-cache is a winner even when you are running two threads that share virtually no memory whatsoever. So why would you possibly go through the trouble of using an L3-cache, when you clearly don't need one?
And obviously, when you DO need to share data between cores, shared L2 beats shared L3 hands down.

So if you're trying to say what I think you're trying to say, then obviously I don't admit to that, because I think it's utter nonsense.

and simply bash it with hardly any logical support (almost as if you don't like it simply because AMD is doing it...).

I've given plenty of technical arguments and actual benchmark figures, you just ignored most of them.
And unlike you, I don't care about the brand that is on technology. Pathetic that you insinuate that over and over again. It's obvious that you are totally in AMD's pocket... so much so that you are no longer capable of reason... but don't assume that others are like you.
As I said, I used AMD systems extensively... the Core2 Duo is the first Intel system I'm using in years. I don't care about brands, I care about the best tools for the job.

 

[Scali2]

A little more information on the quad-core demo:

http://www.theinquirer.net/default.aspx?article=36131

Funny you should post that... it isn't very optimistic to say the least...

Basically, AMD set a deadline of 'before the end of the year' and was then stuck with A1 silicon, good, bad or ugly. This is why you get a demo of task manager, and the press aren't even allowed close enough to play minesweeper. On the other hand, AMD got it to boot Windows, and that is no small task.

If you want to play devil's advocate, Intel showed Tigertown running at speed over a month ago.

That's exactly what I said... no benchmarks, nobody is even allowed to touch it, while Intel already demo'ed its stuff pretty much the way it will be sold.
I don't see why you were falling all over me for saying that, while you post an article that says the same.

 

[visaris]

Funny you should post that... it isn't very optimistic to say the least...

The topic of this thread is AMD's quad-core chips. I posted a link to an article with some information and speculation related to the topic (and very little information related to other topics). Further, I don't understand why it is that you have so much trouble staying on topic, and even find it "funny" when others are able to do so.

----

Another article. This doesn't really have much substance (more of an AMD press release), but if one reads through it, there are a couple of little specs of information in there:

http://electronics.physorg.com/news84203350.html

 

[Scali2]

Further, I don't understand why it is that you have so much trouble staying on topic, and even find it "funny" when others are able to do so.

You seem to be the only one who even thinks I'm not being on topic.
To which I say: lol, grow up!

Everyone can see right through you anyway.
As soon as someone says something you don't like, you start your nonsense.
Why don't you respond to the posts about cache? Oh right, you can't win that one. That's why you're back to nagging about off-topic again in the first place. Pathetic.

 

[digitalx0]

Funny you should post that... it isn't very optimistic to say the least...


That's exactly what I said... no benchmarks, nobody is even allowed to touch it, while Intel already demo'ed its stuff pretty much the way it will be sold.
I don't see why you were falling all over me for saying that, while you post an article that says the same.

Seriously man, get out of his thread if you are going to continue to be like that. He asked you to leave if you can't stay on topic.. so man up, and get out.

 

[duby229]

Scali, seeing as how you two are pretty much much the only ones in here except for a slight smattering of others that are known to be biased, I dont see how you could come to the conclusion you did.

The truth is, this thread is about AMD's native quad core. I could care less how much better Intel's cache is then AMD's..... That is not what this thread is about. It's about AMD's Barcelona, and it's kin.

I already kindly asked once for you to stay on topic, and it sounds like Visaris is pleading with you. What more does it take? You've been asked politely several times.... Please stay on topic.

If you dont have anything to share that is ontopic, then please find something, and contribute positively....

(See that harpoon, Positive versus Negative )

 

[visaris]

- deleted -

Ah, dub said it for me.

 

[Scali2]

I already kindly asked once for you to stay on topic, and it sounds like Visaris is pleading with you. What more does it take? You've been asked politely several times.... Please stay on topic.

It's quite simple: I don't agree with you and visaris that I'm going off-topic.
You and visaris are just making matters worse by continually nagging about it.
If you just don't respond to something you don't think belongs in the thread, then perhaps nothing will happen.
In my opinion this is just pathetic. You two are making it sound like going off-topic is a crime.
I think it's time to call in the help of some moderators to settle this nonsense.

 

[digitalx0]

It's quite simple: I don't agree with you and visaris that I'm going off-topic.
You and visaris are just making matters worse by continually nagging about it.
If you just don't respond to something you don't think belongs in the thread, then perhaps nothing will happen.
In my opinion this is just pathetic. You two are making it sound like going off-topic is a crime.
I think it's time to call in the help of some moderators to settle this nonsense.

Or you can just stop posting in this thread, and all problems will be solved.

 

[visaris]

Nothing that new, but I don't think it has been posted in this thread yet. This is the video from AMD's site; not much substance, but it may be interesting to some of you.

http://www.amd.com/quadcoredemo

 

[Donnie27]

Exactly.Not to mention the extreme difficulties involved in having a cache that large , with exceptional BW , sharing mechanism , good scalability and keeping latency that low.It is simply a tour de force , cache design and execution at its finest.

Notice how a Screen shot equals Demo but hands on tests = FUD WOW!

 

[Scali2]

Or you can just stop posting in this thread, and all problems will be solved.

I don't have to stop posting in this thread.
As far as I know, I haven't broken any forum rules.
So I don't have to listen to anyone (especially non-moderators) telling me to stop posting.
I'm free to post on this forum and in this thread, as long as I abide by the rules. Which to the best of my knowledge I have been doing, and will try to continue doing.
Thank you very much.

 

[InorganicMatter]

The truth is, this thread is about AMD's native quad core. I could care less how much better Intel's cache is then AMD's..... That is not what this thread is about. It's about AMD's Barcelona, and it's kin.

For a thread about AMD's new technology, comparing and contrasting AMD's new cache with Intel's current cache couldn't be more on topic.

Seriously man, get out of his thread if you are going to continue to be like that. He asked you to leave if you can't stay on topic.. so man up, and get out.

He is on topic. You unnecessarily nagging him to stay on topic is the only off-topic-ness in this thread.

 

[Donnie27]

I don't have to stop posting in this thread.
As far as I know, I haven't broken any forum rules.
So I don't have to listen to anyone (especially non-moderators) telling me to stop posting.
I'm free to post on this forum and in this thread, as long as I abide by the rules. Which to the best of my knowledge I have been doing, and will try to continue doing.
Thank you very much.

If you're not blindly agreeing with everything AMD says, you're off topic and spreading FUD LOL! If facts you present are negative, you're thread crapping. Showing something AMD didn't quite do as well is trolling. Pointing out that AMD is BSing someone, well that means you're on the wrong side of the forum! Not posting like a marketing rep from AMD, Priceless

 

[duby229]

For a thread about AMD's new technology, comparing and contrasting AMD's new cache with Intel's current cache couldn't be more on topic.


He is on topic. You unnecessarily nagging him to stay on topic is the only off-topic-ness in this thread.

No it is not at all. Not even one little bit....

Comparing AMD's new cache to AMD's old cache is however. If this was the case then nobody would have had a problem whatsoever.

This is after all AMD's new technology developed by AMD. It would be far better to know what improvements would be made over older technology. I couldnt care any less how much you adore Intel, and it is completely irrelevent.

Stay on topic please. Lets discuss the improvements being made in AMD's new technology please. If you want to compare Intel;'s products, then go into the Intel forum and do that. Until then lets please try to stay on topic.

 

[Scali2]

Stay on topic please. Lets discuss the improvements being made in AMD's new technology please. If you want to compare Intel;'s products, then go into the Intel forum and do that. Until then lets please try to stay on topic.

Isn't this a catch-22?
If your rules would apply, then we can't compare Intel to AMD in the Intel forum either, because that would be off-topic.
Funny how you and visaris have repeatedly said that we should discuss this in the Intel forum... while it would be just as off-topic there.

So what forum should we post it in then, I don't see any other CPU-forums here (except for VIA... but same would apply there)?
You can't possibly say that it would be off-topic everywhere on this forum, because this forum belongs to the HardOCP website, which routinely posts CPU reviews where AMD and Intel processors are compared in-depth.

I'm starting to think that perhaps you and visaris aren't quite right about this being off-topic.

Speaking of off-topic... you've not contributed anything on-topic yourself, you've only nagged about others being off-topic. In fact, you're the one who instigates the off-topic conversations... I originally just ignored it, but you insist, so it's hard to keep ignoring it.
I've already reported your post, so I hope a moderator can settle this once and for all.

Until then I would appreciate it if you would just stop posting about this issue. It's been mentioned repeatedly, it's been noted that you think it's off-topic. Let it also be noted that we don't think it's off-topic. That's all there is to say about it, until a moderator decides what to do about it...

Until then we can at least discuss both the AMD architecture and the Intel one it will compete against. That would be more on-topic than nagging about things being off-topic, so I think it makes for a good compromise for now.

Thank you for your understanding.

 

[duby229]

That is fine.

But you might want to look at the thread title. It doesnt say anything about Intel. It doesnt say anything about cache. It doesnt say anything about comparisons. That is just the simple truth of it.

If you want to post something off topic, then so be it.... But most people at least post something like "OT" or something similar. That is acceptable.....

I'm not trying to flame anyone or incite anything. But this thread was by the Ops own account is not here for anyone to discuss Intel. If the Op says that this thread was created to discuss AMD's technology, How is it your duty to determine whether it is off topic or not.

The simple solution is create your own thread. Be it here, or the Intel forum, or even the Via forum. It dont matter. If you want to compare Intel's quad core chip with AMD's quad core chip, create your own thread with an appropriate title to reflect that.

Simple really.

 

[InorganicMatter]

No it is not at all. Not even one little bit....

Comparing AMD's new cache to AMD's old cache is however. If this was the case then nobody would have had a problem whatsoever.

This is after all AMD's new technology developed by AMD. It would be far better to know what improvements would be made over older technology. I couldnt care any less how much you adore Intel, and it is completely irrelevent.

You can make up whatever excuses you want, I'm going by moderator/owner precedence. Kyle discussed Intel here, which is clearly in the AMD forum, and even said AMD wasn't the way to go right now, so comparing and contrasting across brands is well within the bounds of on-topic.

 

[duby229]

You can make up whatever excuses you want, I'm going by moderator/owner precedence. Kyle discussed Intel here, which is clearly in the AMD forum, and even said AMD wasn't the way to go right now, so comparing and contrasting across brands is well within the bounds of on-topic.

His review. His thread. His topic.

In this case lets respect the op. His thread. His topic.

If you want to discuss another topic. Create your own thread. Your thread. Your topic.

 

[Scali2]

But you might want to look at the thread title. It doesnt say anything about Intel. It doesnt say anything about cache. It doesnt say anything about comparisons. That is just the simple truth of it.

There's no rule that says you can only discuss what's in the topic title. If there was, then there'd be little point in responding at all, because the first post already sums up everything there is to say about what is in the title.

I'm not trying to flame anyone or incite anything.

You are, actually, and you know it.

But this thread was by the Ops own account is not here for anyone to discuss Intel. If the Op says that this thread was created to discuss AMD's technology, How is it your duty to determine whether it is off topic or not.

There is nothing in the forum rules about a threadstarter determining what others can or cannot post in his thread, it doesn't even say that the threadstarter can define what is on-topic and what is not (which is a good thing, else things could become quite arbitrary, and threadstarters could use the excuse of 'off-topic' to shut anyone up). Opening a thread doesn't give you any rights to tell others what to do on the forum.
Only a moderator can decide whether or not something is off-topic, and only a moderator can decide to remove your posts, or even stop you from posting.
You're neither a moderator nor the threadstarter, so it is not your place to go and tell people what they can or cannot post here. So cease and desist.

It just happens sometimes that someone posts something in a thread that the threadstarter wasn't interested in. Such is life.
As long as it all happens within reason (as it does now, as far as I'm concerned), there should be no problem... You however are pushing this into a big issue, where I am forced to report to a moderator in order to settle it. So you are basically creating a problem here. I can only ask why.

 

[InorganicMatter]

^seconded^

 

[LstBrunnenG]

I really want to know what the OP wanted to talk about if we can't talk about how the product will stack up in the face of the competition. Otherwise the "discussion" will go something like this.

"AMD's releasing a quad core chip, it'll be faster than what AMD has released before."
"Cool..."

The thread could be extended by maybe a couple of posts by describing what AMD actually did to make it faster, but if no dissention and no comparison to the competition is allowed, I'd hardly call it a discussion. Announcement maybe? Decree perhaps.

 

[visaris]

More commentary on the demo:

http://www.pcworld.idg.com.au/index.php/id;1286647537