it's a classic.
it's a classic.
Funny, he seems to be more anxious for performance numbers than I am.
It will all show up in due time.
We don't generally release benchmarks prior to the actual launch. If we do, they are typically something like STREAM.
Any information given for software for fusion ? I would looking to know if the gpu part will be used like a co-processor with some actual or new instructions.
And the question i'm really asking myself, is ; Did AMD integrated old x87 or remplaced fully by SSE ? It's die space not anymore really used.
Trying to glean information from a forum thread seems rather outdated, and err... not-so-intelligent. Oh well! Sometimes when you get paid, you gotta do the job. Keep digging though.Quote:
Originally Posted by JF-AMD
Any GPU co-processing is going to come via either directcompute or OpenCL at this point. I doubt you would see us do anything proprietary, we've been pretty strong advocates of standards, especially when it comes to fusion. The fastest way to kill the technology is to make it proprietary (ie. Cuda). I talk to a lot of customers who are excited about cuda but wary to do any real software work on it for fear that their efforts could fall by the wayside because nvidia could decide to head in a different direction.Quote:
Originally Posted by madcho
There is always the discussion that you can wrap cuda in OpenCL to remove the risk, but that just leads to one more layer in the software model which is more effort and one more layer of debugging if something goes wrong.
^^ Wrong thread.This one is about new information on Bulldozer @ Hot Chips,not about SB.
Best to stay neutral on this topic until both products are relased.
It should be remembered though. It's MUCH more interesting when AMD has a superior product than intel.. simply because of they're very much the underdog. So if SB is a better product overall than Bulldozer, then so be it, and really no one is overly suprised. But you better be damn sure it is before you troll about it, because another Athlon, or Athlon 64 would be a tad embarrasing ;)
I have one question here. It's alot of talk about HT vs cores. But why can't Bulldozer have HT too? I'm sure those pipes have lots of idle time in most applications.
According to what Dirk Meyer implied before(maybe one or two years ago, I can't sure), that the Bulldozer has a possibility to have Simultaneous Multithreading in the second(or above) generation. That will mean 4-thread per module. You can refer to what Sun Rock have done before.Quote:
Originally Posted by -Boris-
Because it's designed not to have too much idle states to begin with? That's what the shared front end is all about,maximizing the utilization of all hw execution units(2 int and/or fp).They will actually use a form of SMT in the FP/simd unit anyway.And if they would try and opt for a sort of SMT in int execution units they would have to deal with a whole another level of possible complications and design complexities. It's not impossible but unlikely to be seen even in Bulldozer successor on 22nm.Quote:
Originally Posted by -Boris-
Now, if there's a DP board like SR-2 for BD, it'll be so much more interesting as AMD had the 4P/2P tax removed.
Actually, the shared FPU of the Bulldozer design makes me think about if it was what started the Reverse Hyper Threading thing all along, because you have a single FPU shared bewthem two Cores whose usage should be transparent to the OS.Quote:
Originally Posted by informal
all you black kettles and pots are so amusing.
the very same kettles that accuse the pots of derailing amd threads
are the very same kettles that derail intel threads.
and it will never change because of brandboyism
kettle+view= AMD:up:intel:down:
pot+view= intel:up:AMD:down:
thats why its better to be a potkettle
potkettle+view(AMD:up:intel:up:)=good times ahead(choices,choices and more choices):D
I think that one of the main reasons why AMD is not a big fan of SMT is because it's very hard and complex to validate. SMT doesn't add much die size to the core, but to validate if it actually properly works is a tough job. This complexity means that it costs quite a bit of money to properly implement and AMD has to choose for the most economically efficient way of designing its CPUs. AMD wants the best performing CPU design for the least amount of money it can spend and that means that SMT is not a priority for AMD. That's just my guess though, I'm not sure if there's any truth to it.Quote:
Originally Posted by -Boris-
that's the programmer's fault, not intel'sQuote:
Originally Posted by Chrysalis
the economics of designing a cpu are very important. for intel SMT is not as hard to verify because their hillsboro team has a lot of experience with it. building on to existing tech is important to intel and amd to keep costs down.Quote:
Originally Posted by Helmore
another very important uphill battle for AMD and fabless companies will be verification. with the cost of mask sets going up exponentially having logic bugs will be very costly. getting things right the first time is important.
Slightly random?Quote:
Originally Posted by gOJDO
No he's just trying to emphasize the fact that he indeed is trolling in AMD threads. But his posts are irrelevant anyway,so it doesn't matter much ,if at all.Quote:
Originally Posted by h0bbes
Sorry to learn that you are anxious concerning Bulldozer performance. ;)Quote:
Originally Posted by JF-AMD
---
A performance claim needs to be future-verifiable, otherwise it has virtually no value.
If "the only performance claim AMD is making at this time" is "Interlagos has 50% greater 'total throughput' than MC", we need to know how 'total throughput' is measured in the context of the claim, in order for it to be meaningful.
Otherwise you might as well say, "Interlagos has 50% more QuantiMips than MC."
Then, after release, you could define QuantiMips in any way that satisfies the earlier claim.
---
Speaking of future-verifiable, what about the very specific claim of 60-80% greater specInt_rate (Interlagos over MC) that you made in November 2009?
Why won't you address your own earlier statement? Still operative? Withdrawn implicitly by your recent statement?
One of the most interesting aspects of the BD design (the little we know so far) is the 4 pipelines on each execution unit.
Conventional x86 wisdom says that 1 is used most of the time, 2 some of the time 3 seldom .... so why 4?
JF has assured me in other threads that AMD has a way of keeping those 4 pipelines busy ;)
On the inevitable subject of SMT vs CMT (although that isn't what AMD is claiming it is), both are an attempt at sharing resources on a CPU. I have read quite a bit on the subject, and most experts and researchers agree that CMT scales better and represents a lower design risk. In this day of crazy large cache, the additional die space required for the additional int units is also quite small when compared to the entire die.
This isn't to say that SMT is "fake" cores or any such nonsense as has been marketed. SMT is simply another way to share resources and increase efficiency. It is IMHO a more costly way and less efficient way.
Why not have both? Sun does it? Well, looking at the Intel base architecture, it would require some serious changes since they have implemented a more homogeneous core design ..... that is to say that a single processing unit is responsible for both INT and FPU while AMD has adopted a design where the FPU and INT units have been separated for some time (since K7?).
So why wouldn't AMD adopt SMT? Again, IMHO, it isn't likely isn't worth the headach for them. The refresh of BD is more likely to contain even MORE Int units and be fed by wider schedulers rather than adopt SMT. The ability to share cache and other resources scales much better with CMT than it does with SMT. The abstraction layer is in a bad place with SMT IMHO.
And finally, for the AMD vs Intel debate, both companies have "borrowed" heavily from each other with respect to designs. For those that pound on AMD, remember, AMD has managed to compete successfully with Intel while being 1/50th their size ..... and it hasn't been because of AMD's superior marketing and sales guys (no offense to JF-AMD ;) ). It has been because of a superior product value to the customer.
Yeap. :yepp: Obviously I'm just pi$$ing off some die-hard AMD fanboys.Quote:
Originally Posted by h0bbes
This thread is funny. It's a 10 pages waste in the database, so I'm adding fuel for the next 10 :D
@informal
Intel is better than AMD :D :ROTF: :rofl:
I suggest you dont.Quote:
Originally Posted by gOJDO
goJDo, for so long time ,-)? Maybe than u will AMD boy :)
I would be disapointed serously if AMD choose to take an API for use the accelerator.Quote:
Originally Posted by JF-AMD
The best was to "simply" extand x86-64 to a new instruction set.
Yes not an easy work, but would be a lot faster to get performance improvement, update compilers and re-compile code.
And kill that f*cking x87, free some die space.
And JF : directcompute is proprietary.
Maybe. In the past half year I have bought three times more AMD CPUs than Intel. :DQuote:
Originally Posted by FlanK3r
Anyway, I'm tired of speculations, especially when it comes to AMD. The less you expect, the less you'll be disappointed. ;)
So, until we have some hard BD numbers I call BS on all the speculations.