Neuigkeiten zum K10

JF-AMD schrieb:

Is Socket C32 being designed to be backwards compatible with the existing Socket F?

No. Socket F is a DDR2 design and C32 is DDR3. Having interchangeable processors and memories would mean a massive test matrix that OEMs might find difficult to support. Eventually you’ll have to switch over to the new design. Based on the fact that we expect Socket F to end up with ~5 years of life in it from 2006 to 2011, we feel it has served the market well and we don’t want to be focusing the new generation of processor into a 4 year old platform.

Are you going to allow a C32 socket to accept 8-core or 12-core CPU, or a G34 socket to accept 4-core or 6-core CPU?

We do not have plans to support this. The C32 and G34 sockets are different form factors with different sizes and pin counts and are targeting workloads with different needs in terms of computational capabilities. The C32 and G34 platforms address different form factors and customer workloads. Our goal is to introduce product features (including core counts) that are best aligned to those customer needs.

2. Variante:

No, C32 and G34 are 2 completely different sockets.
We will never allow mixing of these parts, which is what we said.

Does AMD plan to scale into the >100 thread 8P market with G34 systems?

The G34 systems planned for 2010 are expected to offer scalability to 4 sockets each with 12 cores per socket; that represents a total of 48 cores for a 4P platform. The challenge in moving beyond that level for many mainstream business applications can be that the scalability of the software becomes a bigger challenge than the scalability of the hardware. (Specialized HPC-style applications may be another story altogether.) The market for single systems with 96 cores appears to be very limited at the moment, and new technologies like HPC, cloud and developments such as the HyperTransport HNC specification all represent ways of getting greater scalability in a scale out mode vs. scaling the systems up.

2. Variante:

Correct. Some people want black and white, yes and no answers. When you are talking about the future you have to be careful to say "nobody will ever need more than 640K."

Will AMD be the single chipset source for server main boards in the long term?

AMD plans to release the SR5690 chipset later this year (Anmerkung: Ende des Sommers 21.09.2009)[5]. That will be utilized with existing Socket F processors as well as the future “Maranello” and “San Marino” platforms. We can’t speak to the plans of other companies, but we welcome any additional chipset products from other vendors; competition always breeds the best innovation.

2. Variante:

We would greatly welcome other chipsets, the more choices you have, the better the breadth of platforms. The real issue is that I could never comment on another company's products.

AMD has placed a great deal of emphasis on the fact that all of the new Six-Core AMD Opteron processors (formerly codenamed “Istanbul”) fit within the same TDP/ACP as the previous Quad-Core AMD Opteron processors (formerly codenamed “Shanghai”). Can we expect this trend to continue with “Magny Cours” and “Interlagos” despite the increasing core count?

Because we are moving to a new platform (codenamed “Maranello”), there is not a need to have exactly the same TDP/ACP as past processors. We do recognize that customers are very comfortable with the power/thermal bands that we have established and we plan to continue to use power bands that are very similar to what we use today. In general, we plan to continue the approach of allowing a single platform to be able to support more than one generation of processors (though not mixed in the same system of course), sharing a common power/thermal envelope. Just as the Socket F (1207) allowed us to support Rev F dual -core, “Barcelona,” “Shanghai” and “Istanbul,” we believe that “Maranello” will support both the “Magny Cours” processors as well as the “Interlagos” processors. We expect the “San Marino” platform to support the “Lisbon” processor as well as its follow-on, the “Valencia” processor.

2. Variante:

We will never do 200W processors, there is zero demand. The power bands that we have will remain consistent. Will standard power be 75W ACP or 74W ACP or 76W ACP. If I say "exactly the same" and we are off by a watt, I am a liar. The key is, as I said, they will all be about the same, but I don't want someone hanging me over a 1 watt delta.

Zum Vergrößern anklicken....

• There will be no more AM3 servers, socket C32 will replace both the 1000 series today and the lower half of the 2000 series. Socket G34 will replace the top half of the 2000 series and the 8000 series. We consolidate from 3 platforms down to 2, but each of those platforms becomes more flexible. [1]

• Our chipset supports 4 processors, not 8. Obviously someone could create a chipset to address 8 processors, but realistically, with ~2200 x86 8P servers sold per quarter, who would spend the money to create this. If customers want 8P, the Sun 4600 and the HP DL785 are both great servers and will have 8P support with Istanbul. But 48 cores in a 4P Magny Cours will be a very compelling platform in 2010. [1]

• Lisbon will be a server chip, not a desktop chip. The designs for desktop are different from server in the future. [2]

• Sao Paolo was the 8-core and Magny Cours was the 12-core. They were both combined under the Magny Cours name. They will each have 12MB of L3 cache and 4 memory channels. The 8-core will have higher clock speeds. People will buy the 8-core if they need higher clocks or higher cache/core or memory bandwidth/core ratios and will buy the 12-core for highly threaded applications. [3]

• No, the 8-core and 12-core are both based on the Magny Cours die. The silicon will be identical. We will have 4 processors introduced in the first half of 2010:
  
  Q1 2010: 8-core and 12-core Magny Cours
  Q2 2010: 4-core and 6-core Lisbon
  
  The silicon in each of these will be identical, the only difference will be the number of cores. This will make coding and deployment infinitely easier for customers. [3]

• The only thing I will comment on is that Magny Cours will not see a shrink because Bulldozer is the follow on. Shrinks are expensive and time consuming (well, most things in this business are...) so it makes more sense to put those efforts and resources towards Bulldozer.[3]

• The cores will be similar to what you see in the current processors, but they will not be exactly the same. There will be some additions to the core that will add some new functionality. I can’t go into those details now, but assume that Magny Cours will be similar but with new capabilities. [4]

• Desktop and server are different designs staring with Istanbul, so do not take any of the statements I am making to be a reflection of what is happening on the desktop side. [4]

• The MCM of Magny Cours will be connected with HyperTransport, which is the same industry-standard technology that we use to connect processors, chipsets and I/O devices together. PCIe 3.0 is a long way off, gen 2 is just now hitting the market. Having interconnected dies is critical for MCM scaling. Other companies have created MCM parts in the past by simply putting two dies in the same package. But if Die#1 needed to communicate with Die #2, it had to do so through the front side bus and the memory controller, creating more bus traffic and more bottlenecks. Interconnect MCM scales quite well, non-connected MCM does not.[4]

• When we get to bulldozer there will be 2 variants, one for the G34 infrastucture and one for the C32 infrastructure. Both will be compatible with the respective G34 and C32 sockets that you will see on the Maranello and San Marino platforms, so it should be an easy qualification for customers and a consitent platform. We have not released any other data on the bulldozer products, so you’ll have to wait for that [4]

• The product based on the bulldozer core (Interlagos) will fit into the Maranello platform. [6]

• We are already integrating Radeon technology into our STREAM computing and have customers deploying that technology. Expect to see that trend continue. When we say “the future is fusion” we are not just talking, it is in our product directions. [6]

• This has already been addressed. Montreal was not canceled, but there were changes to the definition of the product. When those changes happened, we changed the code names and created Magny Cours (12-core) and Sao Paulo (8-core).

• 
  Then, as we developed the Opteron 4000 series (C32), to simplify the roadmap names, we merged Sao Paulo and Magny Cours together, because otherwise we'd end up with one code name for the 4-core and one for the 6-core to match the names for the 8-core and 12-core counterparts.
  
  People read too much into code names, we simply use them so that we can have conversations in public. Once when I was at Compaq our roadmap leaked and all of our code names were in PC Week. We had to rename all of the projects. They were so strict we could not even have the "decoder ring" - nobody was allowed to have a document showing the old and the new names. When I had to present all of the new names to the VP, I had 2 pieces of paper with the old ones on one piece and the new ones on the other that I held up next to each other. [7]

• HT assist is not much of a benefit with 2P, it is really a 4P play. You give up 1MB of cache in order to cache the lookup tables. So in a 4P, you give up 1MB but reduce the probe traffic and the latency of multiple hops. Good advantage. In 2P, you give up 1MB and you don't gain much in latency because there was only 1 hop to the other proc. HT assist may be available in C32, but it will be of little value; it is much more of a play on G34. [8]

• Shanghai - originally slated for Q1 09 launch, delivered in November 2008 at higher frrequency than planned
  
  Istanbul - originally slated for Q4 09 launch, delivered in June 2009 at higher frequency than planned
  
  Woodcrest - Launched in July 06, not available until September 06
  Clovertown - Launched in November 06, not available until January 07
  Harpertown - Launched in November 07, not available until Juanuary 08
  Gainestown - originally slated for September 08 launch, then November 08 launch, finally launched in March 09.
  
  I see only one company executing to its roadmap on the server side. True, Barcelona was late, but if you recall back at that time, both companies had a TLB issue in their quad core products. We held ours and corrected the problem so that no customers' data was at risk. Someone else issued an errata but never stopped selling their product. I guess we have different philosophies around protecting customer data. [9]

• Yes, it is an old roadmap, but he does have a valid point. There was some shifting around when we put istanbul in, Montreal morphed into Magny Cours because of some product changes. It's a valid point, I should not have used the word "originally", I was working of off the last iteration of the roadmap, not the 2007 version. [10]

• Barcelona dropped into existing platforms, so what makes you think that platforms were at all part of the delay? It was TLB only. Istanbul came up because our partners asked for more longevity on the current platforms. Based on how DDR-3 is still priced these days, they made the right call and getting more longevity out of DDR-2 systems. Montreal beacame Magny Cours after a few platform changes. [11]

• When it comes to memory, we find that overwhelmingly customers want standaardized memory. The idea of "only a few pennies more" falls apart if the supply chain is interupted. Memory generally accounts for a higher portion of the BOM cost than servers in most cases, so customers are real sensitive about this. The idea of having different platforms with different memory is not a great choice either for customers. Just ask Intel customers about having to stock and deal with DDR-3 and FB DIMM. [12]

• G34 and C32 will support both registered and unregistered memory. But the overwhelming majority of server customers will go with registered memory because unregistered memory does not have the expandability that server customers need. [13]

• We never give exact release dates. It (S5690 chipset) will release soon. It will have all of those features as it will be the same chipset used in the Maranello and San Marino platforms. However those features will not be available in Shanghai or Istanbul, only with the newer processors. [14]

• The upgrade path is:
  
  G34: Magny Cours (8-12 core) -> Interlagos (12-16 core)
  C32: Lisbon (4-6 core) -> Valencia (6-8 core)
  
  Just a BIOS upgrade is all you should need. [15]

• Any stepping would not be done to make an architectural change. When we move to MC/Lisbon there will be some functional changes at the architectural level, but you generally don't see changes like that happening in a vacuum.Steppings are generally to resolve some issue on the processor or to increase manufacturability. It is highly unlikely that there would be a stepping just to change the architecture. Those changes get rolled into large architecture changes. Our partners would prefer that we not step the processor unless absolutely necessary. Because customers will generally have to qual, they feel the same way.
  
  Since I am not an engineer, the question I always have is can a change be invisible or will it require some sw change as well? Asking someone to touch their server sw is generally not a fun conversation. [16]

• Of late, AMD seems inclined to design new chips that fit within the thermal and power constraints of their predecessors. If this continues to be true, the individual clock speeds of those cores will have to fall. "Doubling the number of available cores generally means halving the power," Conway said. That generally means a 25 percent frequency reduction, he said. [17]

• Folks, no SMT/HyperThreading. At least not in the thing that I see looking out over the next several years. Websites that deal in speculation on unannounced products don't have a 100% track record. You need to apply a filter to those statements. [18]

• Der CPU Core des Barcelona wird von AMD als Greyhound und der der Shanghai, Istanbul, Magny-Cours und Lisbon als Greyhound+ bezeichnet. [19]

• Well, we do analyst days twice a year. Typically ~november and april. Bulldozer will be the next big server technology preview, but I just ca't vouch for whether it will be in the fall or the spring that we will give the next level of depth.[20]

• Istanbul is our current 6-core die. There will be a stepping to add some new features (I can't say what they are.) This new stepping will be productized in 2 packages.
  
  A G34 package will take 2 of those die, tie them together with HT and make a connected MCM with 8 or 12 cores.
  
  A C32 package will take a single die and make a 4 or 6 core processor. [21]

• Desktop uses the same silicon as server (same # of process steps as I understand it.) The differences are:
  
  1. Server has certification of server OS's
  2. Server has a rated duty cycle that is much longer (like 7x24x365x5 or something like that)
  3. Server has different packaging (except AM3) and cannot be overclocked or unlocked
  4. Server has a different workload calculation for coming to clock speed. [21]

• There is nothing to put in jeopardy. I have been consistent with what we have told the press, customers and the public.
  
  Between now and Bulldozer there is not HT/SMT-type technologies in our processor. Can't say what is beyond that because they only let me see up to Bulldozer (I have a ~3-5-year technology horizon for my job).
  
  We have been pretty clear that we believe that a strategy of cores delivers more predictable results than SMT, which can show small performance increases in some workloads and potentially even performance degradation in other workloads. We are pretty transparent on this topic.
  
  If, in the post-bulldozer timeframe enhancements to SMT allow for real scalability and no performance hit, there is no reason that AMD wouldn't consider it. For now, A.) we don't plan it any time soon and B.) really haven't locked down the post-bulldozer products 100% yet. [22]

• Bulldozer is a completely new architecture, from the ground up. Any assumptions that you make today are based on your knowledge of existing platforms, not the future platforms.
  
  When you make definitive statements about what bulldozer will/will not be, you run the risk of being wrong. Just as most of the web speculation is wrong as well. I can't comment on the product until we release more data, but I will say that many of the commonly heald beliefs about processors may change in the bulldozer timeframe. [23]

• As excited as I am about our current products, I can’t resist the temptation to mention the Six-Core AMD Opteron EE processors (codenamed “Lisbon”) that we’re planning to introduce next year. These six-core processors are planned to have a rated power consumption of less than 40W - that’s lower than the rated power consumption of most of today’s quad-core mobile processors. A processor that combines the registered memory and RAS (reliability, availability, and serviceability) features of a server processor with the power consumption of a mobile processor? [24]

• Magny Cours power and thermals will be close to the existing products, not 2X. There is little or no market for 150W server parts. [25]

• I can't speak to the desktop but you will see 4 HT links on MC aw well as higher HT performance. 4 HT links on a desktop would be worthless because those links are for connecting processors and you only have 1 Processor on desktops. 4 links would just eat up power with no benefit. [26]

• Zum Thema "Turbo Boost" für den Bulldozer:
  There will be similar technology, but I believe we will have a better implementation. [27]

• Sandtiger:
  
  A. Is no longer a pltform, that morphed into Interlagos
  B. Was never defined as an AM2/AM3-class product [28]

• Magny Cours reference board. 8 DIMMs per socket, but the processor will support 12 per socket: Bild 9 [29]

• No, my internal date for Interlagos has not changed at all; internally we have been driving to the same time frame for quite some time. We had been telling the world 2011 for a while, and now that we are within a certain window, we give a half year granularity that is 2nd half.
  
  If that causes people to who assumed first half to think we slipped it, I can't control that. I know that we haven't said Interlagos in first half, previously it has only been "2011".
  
  Not sure what you mean by "sample base on 45nm." [30]
  
  Klarstellung von JF:
  
  I think this is a misunderstanding. I meant that in the 2nd half of the year we would provide more granularity to our partners, not that we would be shipping in the second half of the year. [54]
  
  Ähnliche Aussage:
  
  Folks, we plan our roadmap disclosures based on how close we are to launch. The cadence is:
  
  Year -> Half year -> Quarter -> Month -> Date
  
  For the past year I have been saying "2011" for Bulldozer, but now that we are closer I will say 2H11. It has always been 2H11, but we don't provide that level of granularity.
  
  The problem is that some people assume that 2011 is January 1st and others assume it is December 31st. When it moves from "2011" to "2H11" someone will always say that we slipped the schedule. Since the product has been reclassified as 32nm (I think more than a year ago) all of the schedules have held constant. But I am speaking for server as always I have absolutely no clue what is being said on the client side. [55]
  
  Dazu folgende Richtigstellung:
  
  No, that is me making a mistake. [56]

• I have already said this many times. Magny Cours is a 45nm design that leverages much of the current architecture that you see today in Istanbul (with some new features added).
  
  ...
  
  And, for the record, migrating features from one architecture to another is not a trivial feat. Simple additions to an architecture can move the availability out by several quarters. Especially on a processor that is so close to being launched. Many partners are on their second round of silicon samples at this point, so all of the work done in validation would have to be scrapped and restarted. (gepostet am 20.10.2009) [31]

• C32 is based on the current 1207 socket. By choosing a socket infrastructure that is already in the market we can cut down on the socket cost (the product is targeted at cloud and low-cost environments.)
  
  We did change some pin assignments in order to support DDR-3 (and higher capacities of memory). So a current 1207 will not fit in a C32 and vice-versa. They are the same physical size but the sockets are keyed differently.
  
  2 channels of DDR-3 per socket, 1333MHz support. Support for 1 or 2 procs and they use the same 5650/5670/5690 chipset. [32]

• Interlagos:
  
  12-core = 6 bulldozer modules
  16-core = 8 bulldozer modules
  
  OS will see 12 and 16 core respectively.
  
  The Bulldozer module is a logical way to group components and allow for better power efficiency and a more modular scalable path.[33]

• Cool speed ("AMD CoolSpeed™ Technology") is not turbo. Cool speed monitors your core temps. If they get too hot it drops the proc down one P-state to allow it to cool off, then returns it to top P-state. [34]

• Module is the combination of two "cores" and an FPU. We are saying bulldozer module and NOT bulldozer core to talk about that grouping because it will appear to the OS as 2 cores, not one.
  
  When I was talking about power consumption, I was doing some quick math. We have an HE power band that will be ~55W ACP (based on where we are today.) So if you take 55W and divide by 16 cores, you get about that number.
  
  Keep in mind that I do not have silicon in my hands and the actual ACP doesn't come until right before launch (you need final silicon for that measurement), so I was making an extrapolation, not making a statement. [35]

• OK, each bulldozer module has an L2 cache, so the 2 integer cores share an L2 and all of the modules in a die share an L3. [36]

• Since I have answered the question at least a dozen times, let me be completely explicit here.
  
  The graphic that you saw for analyst's day was a bulldozer MODULE. There is no such thing as a "bulldozer core." The cores inside the Bulldozer module are integer cores, NOT bulldozer cores.
  
  Here is how it works.
  
  A Bulldozer module has the following: 2 Integer cores. One 256-bit shared FPU (that can be addressed as a single 256-bit unit or 2 128-bit units per cycle). Shared front end. Shared L2 cache.
  
  Each Bulldozer module is seen by the OS as 2 cores. The OS does not see a module, only cores.
  
  Interlagos has 8 Bulldozer modules for a total of 16 cores.
  
  Valencia has 4 Bulldozer modules for a total of 8 cores. [37]

• Same die, same uplift, so yes, it applies to Lisbon as well. (Bestehen Magny-Cours und Lisbon aus dem gleichen Die ? Haben beide die gleichen IPC Verbesserungen?) [38]

• 1. Bulldozer is NOT split into 2 smaller cores. Each core has more capability than our existing architecture
  2. For single thread applications you will see better performance than the existing architecture
  3. For single thread applications, merging two cores together would do nothing for you because single core performance is more tied to clock speed than any other variable.
  4. This architecture will launch in 2011; by that time most workloads and operating systems are going to be very optimized for multiple threads. If you have a single threaded application in that environment, it's probably not going to perform as well on anyone's architecture.
  
  If your biggest concern in 2011 is single thread application speed, you might want to stick with your current processors. That is like complaining about 16-bit application performance when the world moved to 32-bit. Eventually it is going to have to happen. [38]

• We didn't do this to counteract HT. We did this to get greater performance within the same power/thermals and get better power efficiency.
  
  The OS will see it as 16 cores. The hardware will see it as 16 cores. If we called it 8 cores that would be more confusing. What you see is what you get. No explanations. The only ones that will see the modules are the designers, they are not visible anywhere but the architectural diagrams, which few customers know about. [39]

• Two threads come into the bulldozer module, each thread is scheduled on its own dedicated integer core (not shared like SMT).
  
  If an FPU command needs to be scheduled, it is dispatched on the same cycle through the FPU. Both integer schedulers can dispatch an FPU command at the same time on the same cycle. The the shared FPU unit could run complex math from 2 different threads at the same time. [40]

• You will not see single core performance increase by 60%, but you will see overall processor throughput, by socket, go up by more than that. A lot more. (Bulldozer) [41]

• If you were to strip one integer core out of each of the bulldozer module, moving them from two integer cores to one, you would only reduce the size of the unit by ~5% (5% mehr Die-Fläche bzw. 12% mehr bezogen auf ein Modul) as well.
  
  So, for 5%, you can have SMT (10-20% increase in performance, or negative increase in performance) or you can have bulldozer (80% increase in performance.) The choice is yours in 2011, buy whichever you believe is the better architecture. I just can't see someone wanting 10-20% when you can get so much more with Bulldozer. [42]

• The 16-core Interlagos will be an MCM, so there will be 2 dies inside the processor connected by HyperTransport. Each die has 8 cores that share the L3 and northbridge, so that each 16-core Interlagos will have 2 northbridges and 2 L3 caches.
  
  The limitation of the L1 cache is really tied more to my understanding than anything else. Johan asked if there were any changes and I said not that I am aware of. There may be changes, but I am not aware of them, and we have not revealed any details. [43]

• Magny Cours = 50-60% faster than Istanbul
  Interlagos = 60-80% faster than Magny Cours
  Both of these are conservative estimates which I personally believe are too low, but I don't get to make the call on that. [44]
  
  Nach dem Start des MC (mit einer höheren Leistung als damals erwartet) ergibt sich aktuell folgendes Bild:
  
  All references were relative to Istanbul. We had no final silicon for MC when we made that assumption.
  
  Original statements: Magny Cours is 50% faster than Istanbul; Interlagos is 80% faster than Magny Cours.
  
  Then we get final silicon of Magny Cours. It performs way better than we were expecting. Instead of 50% faster, we are 86.9% faster. But remember that Interlagos is a brand new core, it is not an enhancement on the old core, so the fact that Magny Cours increases over expectations does not necessarily push up the Interlagos numbers because that is a new/different architecture.
  
  Now, we know more variables, we know 2 of the data points instead of just 1 (Istanbul). So, when you do the math of what Interlagos will be relative to Magny Cours, you are figuring that performance increase based on the real data for MC, not the expectation.
  
  If you lay out the two expectations, you see that the uplifts are about the same off of Istanbul, they are within ~3-4% of each other, so the original Interlagos expectation of performans is still pretty solid relative to Istanbul.
  
  Then:
  Istanbul 100% -> Magny Cours 150% -> Interlagos 270%
  
  Now:
  Istanbul 100% -> Magny Cours 187% -> Interlagos 280% [73]

• I have seen the full bulldozer design. [45]

• No announcements regarding a tape-out of Bulldozer have been made to-date. We continue to track to our engineering timeline for products based on the Bulldozer core and we are on target for a 2011 launch. [46]

• Turbo für den Bulldozer?
  
  We will have some similar technology, but there are some distinct differences that I can't get into. I have never been a big fan of this type of technology (most customers that I talk to want to drive power down, not up) but for those that want to see a turbo boost, there will be some better advantages from AMD. You'll find out around launch. [47]

• Guys, the engineers have done the math. The additional circuitry increases the total floor space of a module by about 12%.
  
  Four incremental cores adds ~5% total real estate to the whole die.
  
  Let's say for fun that the "other" components of the die = 60%. That is NB, mem controller, HT, cache, etc. Then you consider that the 4 modules = 40%, right?
  
  Let's say that you doubled real estate of the modules. That is a 100% increase. Now you are at 140%.
  
  So the 40%, under the new die size represents only 28% of the total die.
  
  So, when you consider that you are dealing with only a portion of each of the modules, and there is things like a shared L2 cache in the module, it is clear that the total die space increase could easily be 5%.
  
  It's math folks. [48]

• We aren't commenting on cache size, but we do recognize that L2 caches seem to be under sized on Nehalem. [49]

• Well, once you tape out, you are technically "in production" because you are making test silicon at that point. We call "production" when we are making parts for sale, not parts for test. [50]

• G34 was designed around the needs of Bulldozer. All of the motherboard design specs in the layout rules were designed around bulldozer, not magny cours, so the expectation should be that it would be an easy upgrade, like shanghai to istanbul. [51]

• Yes, power and thermal are identical (Magny-Cours --> Interlagos). You will need to do a BIOS upgrade, but after you waste those 3 minutes of your life, it's only a couple of minutes to get the new processor in. I change processors almost monthly because I get all the processors I want for free. Between system builds and upgrades I have probably pulled the arctic silver out at least 50 times this past year. It's always a 5 minute operation. Bulldozer should be the same. [52]

• 
  I wouldn't necessarily say that the integer comment is correct. For instance, MC has 12 cores, Interlagos has 16 cores. 33% more cores but more than 33% greater performance (bei gleicher ACP). That sounds like faster to me.
  
  That is the whole idea of the architecture, flexibility for multiple designs. Not necessarily sure that the FPU goes by the wayside, at least not until the software situation changes. There will still be regular applications that need to access floating point for a cycle or two, and FPU will be necessary for that. However, I would expect, that over time, a GPU can plug into the architecture the same way as a bulldozer module. [53]

• Well, too many people are assuming that a Magny Cours is simply 2 istanbuls in a package. That is not the case. There are plenty of new features, not to mention higher speed DDR-3 memory. [57]

• Octo-Core Magyn-Cours aus Lisbons oder Shanghai Dies?
  No, based on 2 lisbon dies. Shanghai is 2 steps back from MC. [58]

• Yes, we are shipping for revenue (to OEMs). And if you run virtualization you will LOVE this processor. 12 cores, 4 memory channels.
  
  I was in the lab yesterday and asked our power guy if it was really in the same power and thermals as Istanbul (6 core). He not only verified that, but also said that it idles lower. Of course, 12-core workloads are generally well threaded, so you won't probably see these at idle as much, but good to know if they do,having 2x the cores doesn't boost power consumption. [59]

• So Lisbon and Thuban are different. I am not aware if this is a different mask or a fusing option. My gut would tell me a mask difference because they don't want HT Assist (it's really not of value for single processors).
  
  We will all use the same cores and memory controllers, but there are distinct difference. Based on the feature sets, that would lead me to guess that they are different masks. But I don't work in development so I can't say for sure. [60]

• 1. Well, it will be hard for the competition to knock 12 cores because they are pushing Westmere as a "12 thread" and Beckton as "16 thread." Is software ready for it? In most cases, yes. In some cases, no. Don't use these for file/print sharing and expect more performance. But HPC, database, virtualization, biz apps (BI, java, etc.) and web/cloud will all be able to take advantage.
  
  2. 4 channels of memory at 1333 is going to be huge. 33% more bandwidth than 3 channels and ~20% more bandwidth than 4 channels @1066.
  
  3. Yes, there will be new features and some core tweaks that will make the clock to clock performance higher than Istanbul. [61]

• 
  5GHz? Only if the chips were powered by magic unicorns. Expect higher clock speeds on those processors than you see today, but not 5GHz. [62]

• The new AMD Opteron™ 6100 processor includes C1E, a new low power state to help conserve energy when in idle. While we know that customers looking for 12-core processors are looking for the highest amount of throughput, we recognize that there are some times where the processors may be in idle states. During these times, through C1E power states, the memory controller and HyperTransport™ 3.0 technology links are turned off, reducing the amount of power consumed by the processor. Because of this new technology, systems based on the new 12-core processors are capable of idling at a lower rate than systems based on our current 6-core processors. [63]

• 
  SC? Do you mean supercomputing?
  If so, think about this: Gigaflops on a 12-core processor: 12FPUs x 4 instructions per cycle X 2.2GHz = 105.6GFlops per processor. And that is not top bin. We will have 3 processors that achieve greater than 100GFlops. And you will probably see a lot of people using them in 4P systems. Can't say why just yet, but there will be some reasons. Compare that to 76GFlops for a 3.2GHz westmere (130W) or 70GFlops (95W) and you start to see the real impact to supercomputing. Especially when you consider the cost of those GFlops for each. It will be a good year on the top 500, probably more in November than June because it takes a good 6 months to get these systems up. [64]

• Actually, there were some minor core changes. It is almost impossible for our engineers to go from one stepping to the next and not add a series of tweaks to improve performance and efficiency. These are generally things that unless you are under an engineering NDA and work for one of our big OEMs, you wouldn't have access to the details.
  
  The architecture did change as we added some APML functionality to enhance what was already in Instanbul, we added C1E for power efficiency and we also added some layout changes. One of the coolest things that I saw is that we laid out a "left" and "right" die that allow for closer connectivity inside the package. It doesn't really impact performance but it will have a manufacturability benefit. [65]

• 
  Yes, the situation tends to work itself out through JEDEC vs. through proprietary buffer technology. Bulldozer will have higher memory capacity than MC. [66]

• 
  Realistically, the 8P x86 market is shrinking. The total market is 1600-1800 servers per quarter. With 48 cores with MC and 64 cores with BD, the need to drive to 8 sockets or more is becoming smaller with each passing day.
  
  Most people buying 8P x86 systems are looking for the large memory footprint more than the large number of cores. With Magny Cours you get up to 512GB and with Interlagos you are at 768GB of memory. Doing that with ~$5.5k of silicon makes so much more sense than trying to use the $29K of beckton silicon to get to a large memory footprint. With an extra ~$24K you can buy a lot of memory. [67]

• 
  People are not buying 12-core processors if they are expecting a lot of idle time. From a server perspective, more are asking for a lower power consumption than higher power consumption, which is what turbo does.
  
  With bulldozer there will be an intelligent turbo mode, can't talk about that, but think of it as turbo done right.
  
  Will you notice another 133MHz on your processor? Probably not. Will you notice the greater power draw? Yeah, you'll see that in your bill. I have never been a fan of turbo for servers. [68]

• 
  A lot of the speculation is wrong. Interlagos will have 33% more cores. The performance at the socket level will be significantly above that, which indicates greater performance per core. Some will be IPC, some will be platform. I won't get into how much or how it happens. [69]

• 
  Bulldozer has more pipelines than our existing products. [70]

• 
  Integer resources are not 2 wide. [71]

• 
  Bulldozer = Architecture code name
  Orochi = Core code name
  Zambezi = Client code name
  Interlagos = Server code name
  Valencia = Server code name [72]

• 
  You will see enhancements to what has been launched on the client side, but you will probably not see any details until launch, this is an area that we are being pretty quiet. [74]

• 
  Performance: We release benchmarks at launch, so don’t expect too much detail there anytime soon. From a performance standpoint, if you compare our 16-core Interlagos to our current 12-core AMD Opteron™ 6100 Series processors (code named “Magny Cours”) we estimate that customers will see up to 50% more performance from 33% more cores. This means we expect the per core performance to go in the right direction — up. That is all I will say until launch. [75]

• 
  Here is a tip: The performance that I gave you was throughput for 12 cores vs. 16 cores.
  
  People took that, did quick math and came up with a "single threaded" performance gain that was massively wrong. You can't determine the single threaded performance from what I gave you. If you ran a single threaded app on MC and then ran the same on BD, the number would be significantly higher. There are architectural reasons why and I am not able to share that at this time.
  
  Anyone that has a single threaded performance estimate from MC to BD that starts with a "1" or anything close to it is using old architecture assumptions on a new architecture and is greatly underestimating the number. [76]

• 
  No. (JF zur 2 MiB Angabe für den L2-Cache des Bullsodzer in seinem Blog)
  
  But if you remind me of this after launch I will tell you the funny story behind it. [77]

• 
  two additional sockets. no other info is being shared. [78]

• 
  OK, this thread is bugging me.
  
  1. They are real cores. Period. If anyone believes otherwise, please post up your exhaustive list of all of the reasons why so that I can address it once.
  
  2. The words "about" and "up to" are words that make my lawyers happy. On the internet you all get to be anonymous. I am known. All of my statements are conservative.
  
  3. The 80% number keeps getting thrown around. Nobody understands it. The number that we have said is that 2 bulldozer cores in a module would be 180% of the throughput for a single bulldozer core. 90% + 90% = 180%. So the "overhead", so to speak, of the architecture is ~10% per core.
  
  We have an 8-core die that in simple terms is 4 modules, or 180+180+180+180 or 720.
  
  If we did not share resources we would have 6 cores at 100% in the same die size or 6x100=600.
  
  So more total throughput from having more cores, by ~20%.
  
  4. We will not ever market modules. It is only a way to talk about the architecture. Modules are a new way to design an architecture. Trying to relate them to HT is wrong. This is a new architecture, you cannot use the old paradigms to describe it. Calling a module a form of HT is like calling a car a "horseless carriage." [79]

Zum Vergrößern anklicken....

JF schrieb:

Let me explain clearly to everyone what is going on.

There are bulldozer modules, not bulldozer cores. Let's all get on the same page here and this will go a lot quicker. Half of the problem is someone confusing a core for a module.

I will use interlagos for this explanation since I am in the server business (I will never comment on desktop, don't know enough about that business.)

Interlagos is a 16-core processor. It will have 16 logical integer cores and it will appear to the hardware and OS as 16 cores.

An interlagos will be made up of EIGHT bulldozer modules. Each module will have 2 integer cores plus a shared 256-bit FPU (which we will get to in a second). 8 x 2 = 16.

Each integer core will run one thread (there are 4 pipelines). That means 2 cores per module, simultaneously.

The FPU is 256-bit. During each clock cycle it can be either 256-bit for either core OR it can be 128-bit for each core simultaneously.

Now, on to HT. Proponents of HT claim "performance improvement with ~5% die space increase." The problem with the performance increase is that it is generally ~10-20%. Sometimes it is negative (in which case they recommend that you turn off HT). So, as a tradeoff, 5% die space for ~20% performance increase seems fine, right?

Well we had our engineers do the math on our core. If I took an Interlagos (16 cores, 8 modules) and pulled out half of the cores, I would save ~5% of the die space. You see, there is a lot on the die other than the integer cores. There is cache, northbridge, FPU, etc. In our case, a 16-core interlagos should perform ~80%+ faster than an 8-core Interlagos. With ~5% more die space.

Some will still try to argue HT as a better technology, but it boils down to this: If you are going to add 5% die space to a CPU, would you rather have 10-20% performance increase (with the chance that it is also negative) or would you rather have 80%+ performance increase.

We believe that real cores and real threads give you the best performance.

Zum Vergrößern anklicken....

JF schrieb:

For some reason I just don't see people comparing a 4 core Intel product to an 8-core AMD product and calling it a fair comparison because they have the same number of threads.

Let's say, for fun, that the IPC performance is exactly the same. If HT gives ~20% advantage for two threads over a single core and Bulldozer gives ~80% for two threads over a single core, then the math looks something like this:

Intel - 4 cores + HT = (4 x 1.2) = 4.8 cores

AMD - 8 cores = (4 x 1.8 ) = 7.2 cores

So, that means, in terms of throughput, that even if Intel has ~50% IPC advantage, they should should still be even.

This of course can be thrown off even more if my numbers are conservative (most of our performance statements are vetted through a pretty conservative group of lawyers before they are made) and if my HT numbers are high. Remember that there are places where HT actually provides negative performance gains (anand is giving ~7-10% for integer/FP performance).

I just have to think that nobody is going to compare an 8-core AMD to a 4-core Intel.

Zum Vergrößern anklicken....

JF schrieb:

I think the difference between 50% and 5% might be the difference between marketing and engineering. Engineers tend to be very literal.

If 2 cores get you 180% performance of 1, then in simple terms, that extra core is 50% that gets you the 80%.

What I asked the engineering team was "what is the actual die space of the dedicated integer portion of the module"? So, for instance, if I took an 8 core processor (with 4 modules) and removed one integer core from each module, how much die space would that save. The answer was ~5%.

Simply put, in each module, there are plenty of shared components. And there is a large cache in the processor. And a northbridge/memory controller. The dies themselves are small in relative terms.

Zum Vergrößern anklicken....

In the Magny-Cours example, the six cores in each of two identical dies exchange data with cores in the other die through an embedded full link and embedded half link as depicted in Fig. 2. These data transfers are additionally managed by the die-to-die communication link (DDCL).

Zum Vergrößern anklicken....

The Scorecard

There’s an old saying in baseball - “you can’t tell the players without a scorecard.” In this age of always-connected information, that scorecard is the internet. It’s amazing how accurate that information can be. And not be. All at the same time.

I am constantly asked about our different products, both existing and future. Clarification of what the AMD Opteron processor products are and where they are targeted is a common request, so I thought it might be a good idea to put it all down in one place; a “cheat sheet” for the IT professional. When it comes to the future products, you might see a lack of details. This is on purpose, as there is some information that we don’t release until we launch the products. (When we discuss the target markets, we are speaking in general terms, because, depending on applications, actual processor choices could vary. That is why we recommend talking to your OEM or system integrator to choose the best solution.)

The Current lineup:

Quad-Core AMD Opteron processor (formerly codenamed “Shanghai”) - This is a 45nm quad-core processor with a 6MB level 3 cache. It fits into all of the existing Socket F (1207) systems and is targeted at current workloads like web services, network infrastructure, departmental applications, technical workloads, and those applications that favor clock frequency over thread count. It is productized as the AMD Opteron 2000 Series processors (2P) and AMD Opteron 8000 Series (4P and 8P) processors.

Six-Core AMD Opteron processor (formerly codenamed “Istanbul”) - This is also a 45nm design that is based on the same core as the Quad-Core AMD Opteron processor, but the design includes 6 cores, not 4, teamed up with the 6MB L3 cache, and plugs into the Socket F (1207) systems. Because of the higher number of cores (12 cores in a 2P system and 24/48 cores in a 4P/8P system), customers typically use these processors for workloads like cloud computing, virtualization, database and HPC where workloads can be very threaded.

Quad-Core AMD Opteron processor (formerly codenamed “Suzuka”) - This is the single socket version of the “Shanghai” die, focused on 1P servers that are typically utilized for web serving, remote locations or running small businesses. You’ll see all of the same features of the “Shanghai” processor, with the exception that it is available only in the standard power band (which is by far the most popular choice for AMD Opteron 1000 Series processors.)

The Future Lineup:

In Q1 2010 we plan to introduce the “Maranello” platform, featuring the processor variant currently codenamed “Magny-Cours". This is a new socket (G34) and the processor is expected to merge both the top end of the 2P market with the 4P/8P market, all conveniently in a single processor, the AMD Opteron 6000 Series processor. Core choices are expected to be 8 and 12 cores, with massive memory scalability through the 4 channels of DDR-3 memory per processor. By utilizing the same processor for both 2P and 4P designs, the AMD Opteron 6000 Series processor should enable several very interesting and flexible platforms with scalability of 16 cores through 48 cores. Clearly this processor is targeted at virtualization, HPC, database and business applications.

In Q2, we plan to introduce a new platform for web, cloud and infrastructure applications - the “San Marino” platform, featuring the 4-core and 6-core processor variants currently codenamed “Lisbon” in the C32 socket. With low core counts, these processors are expected to be a favored choice for applications that scale well up to 8-12 threads. The platform choices around “San Marino” are expected to help OEMs optimize their C32 systems for low power consumption and low cost. We believe these AMD Opteron 4000 Series processors will have the potential to help users achieve new levels of price/performance and performance/watt. When you walk through a data center and see rack after rack of servers, it’s clear that reducing the cost and power footprint of the “workhorse” servers can have a huge impact on the bottom line. Two channels of DDR-3 memory help provide the right level of scalability for these 1P/2P designs while contributing to low power consumption and cost.

Best of all, while the C32 and G34 sockets are physically different, the chipsets, cores and main BIOS core functions are expected to be common across both of these platforms, helping enable OEMs to develop platforms around AMD offerings, and contributing to easier deployment and management by end users.

The consolidation of 1000/2000/8000 to the 4000/6000 product line is expected to reduce the number of overlapping platforms, increase commonality and flexibility for customers, and reduce the overall SKU count for OEMs - contributing to more flexibility and cleaner scalability from 4 cores to 48 cores. Truly a re-definition of the server market that focuses on how industry partners take products to market and customers deploy instead of how processor manufacturers see the world. Customer-centric innovation.

Power Bands:

Customers have a variety of needs, and it would be foolish to think that one processor can solve all of your processing challenges. So, just as we have different models (1000/2000/8000 today and 4000/6000 in the future) we have different power bands to meet specific power needs.

By far the most popular model is the “standard power” with a 75W ACP (average CPU power), which doesn’t even have a designator. This is “Opteron classic” if you are filling in your score card, the choice for price/performance. In addition to this model, there are 3 specialty power bands:

SE - for those that want relatively higher raw performance. By driving to a 105W ACP, we can increase the clock speed for customers running frequency-dependent applications.

HE - Delivering a lower ACP (55W), the HE processors focus on delivering great price/performance/watt for environments where power may be constrained/more expensive or where density is an issue (like with blades)

EE - This is the specialty processor that delivers absolutely the lowest power consumption of any AMD Opteron processor, with a 40W ACP. Customers, like cloud/web 2.0, look for processors like the EE to help reduce the total power per rack because they are in extremely dense environments.

The “Maranello” platform is expected to support SE, Standard and HE power bands, and the “San Marino” platform is planned to support Standard, HE and EE power bands.

So, there you are, a full lineup of heavy hitters - it should be a great game. With this score card you’ll be able to tell who is at bat and who is on deck, so sit back and enjoy the game.

Zum Vergrößern anklicken....

JF-AMD schrieb:

Whenever you see something and ask yourself "why would someone NOT do that?" just keep in mind that we are all very smart people, and our competitors are all very smart people as well. If something is not done by either company it is typically because of one of the following:

1. ROI is not there - it costs more money than it brings in
2. The benefit is not there - the tiny incremental gain will not justify the work or the price you would have to charge
3. The market is too small - even if we build it, they will not come
4. It is not technologically possible
5. While we could do it, our partners would never accept it

Henceforth these will be know as "JF's 5 reasons." I can never tell you why something is or is not being done, but I can tell you, if you ask, that it had to be one of the 5.

For instance, let's take the idea of a 150W server processor. Clearly it could technically be done (4), it would be fairly low impact (2), and there would be a perceived benefit (2). But, the market is really small (3), our partners probably wouldn't want the part (5), and, if our current test equipment could not handle it, it could become real expensive (1). What one person perceives as "just bin to a higher tdp" suddenly has lots of implications beyond sort.

When you spend a good chunk of time in a conference room analyzing your roadmap and your competitor's roadmap to fingure out how it will all play out, you get an opportunity to do a lot of "what ifs".

There are probably few, if any things that spring up on the streets that we have not thought about in one way or another. Unfortunately, with as competitive as this business is, there is no "low hanging fruit" that isn't getting done, on either side.

Zum Vergrößern anklicken....

JF-AMD schrieb:

Hmm, not sure who said what, but let me try to help you with something, and I mean this in the nicest way.

The semiconductor business is a very expensive business to be in and the costs are a lot higher than you would expect. To take a design like Shanghai, which is in a socket 1207, and adopt it to AM3, could probably have a price tag of ~$3-5M or so. Not a big deal if you think that you can make more than $10M in profit. But, if there is another project that can make $20M in profit, that would get the resources. Nobody, not even our competitor, has unlimited resources to do everything they possibly want to do.

So there are tradeoffs based on available resources, costs and the potential size of the addressable market.

You should never take the statements that I make as the "be all, end all, forever truth." But, if I tell you that something isn't going to happen, you should *generally* assume that a.) we have probably looked into it and b.) have determined that it does not make business sense because it either does not make the cut for resources. Otherwise I would probably reply with "good idea, we should look into that."

I am guessing that the frustration that some have is when folks (not speaking directly to you) hear something is not going to happen and reply with "still, I don't understand why you just can't...." There are far too many variables to discuss here on a board, sometimes because of length and sometimes because of confidentiality.

I hope people aren't trying to stifle the conversations here because an open dialogue helps everyone, but I can see how there can be frustrations with some after something has been covered and the line of questioning continues.

I hope we can all just get along.

Zum Vergrößern anklicken....

JF-AMD schrieb:

I have specifically stayed out of this thread. It is similar to the threads that say "why don't they spend millions in advertising" or "why don't they make faster products and bring them to market quicker."

Some of this is a no-brainer. Make a leading edge product, advertise the hell out of it and sell it everywhere. Easy to say, VERY expensive to do.

In today's world, you have to make choices about where you apply resources. Staffing a channel is very expensive in any country. There is an entire back-end organization that needs to be there, from sales to marketing to support, to supply chain, and more that you don't even see. You can't just go to the leading distributor in Brazil, for instance, and say "carry my product" and have them do that. There is promotion, there are logistic.

We are well aware of the aggregate size of every market and we are trying our best to address all of them, but, based on resources, some markets are easier to penetrate.

Trust me, this actually is rocket science. I've been doing worldwide channels for close to 20 years now - it is difficult and requires a lot of resources. Please don't walk away thinking we don't care about you.

Zum Vergrößern anklicken....

JF-AMD schrieb:

Well, there are different teams of engineers, just like there are different teams of people building a car on the ford assembly line. Since I don't know which groups are which (because I only deal with the end of the line) I will try to put it into broad steps (from my limited knowledge.)

The major steps are:

Architecture design - figuring out the instruction flow, logic and technologies
Circuit design - figuring out what should be a 0 and what should be a 1
Floor plan - figuring out what goes where
Development - actually pusing through the project to completion
Validation and test - self explanatory
Sustaining - post launch

All of these teams are specialists, so the projects generally flow through the groups. The design teams (doing circuit design and floor plan) are the ones that "live" with the product over the longest period of design. Typically that is 1-2 years from my experience.

Again, I could be really off base (or be over simlifying) but, from the folks I come in contact with, this is the general flow.

Zum Vergrößern anklicken....

JF schrieb:

You don't try to make samples to prove something out. All samples are supposed to be fully functioning chips. You have proto, EVT and DVT silicon. Generally 3 spins.

With Istanbul we got it right on the first try and generally released the first silicon. That was an exception, but it got us to market 5 months early.

You target final silicon, you rarely get it.

Zum Vergrößern anklicken....

JF-AMD schrieb:

ACP is 40W.

To get ACP we start with "hot" parts out of the fab. These will be parts that would draw more power and kick off more heat (assume they fall into the "worst case scenario" for parts a customer would see.

Then we take the 5 or 6 biggest server benchmarks that represent real workloads. We run these at 100% utilization and measure the power for every half second for a set period of time (several hours I believe.) We pull the average of the 100% utilization, not the average from 0-100%.

From that we get ACP.

TDP is the actual max power the part could ever consume. That is very different from our competitor who has a TDP and a max power (which they do not publish readily.)

Think of TDP as the top reading on the speedometer. ACP is how fast you drive to work when you are really late.

Zum Vergrößern anklicken....

JF-AMD schrieb:

Actually ACP came from our customers. They were having issues because our old 95W TDP parts rarely drew more than 50W. So we had customers making decisions that our 95W TDP, which rarely ever got above 50W was the same as our competitor's 95W TDP. Dempsey, for instance, had a 95W TDP and A 174W MAX POWER.

If someone wants to say ACP is an imaginary number, it is no more imaginary than our competitor's TDP at this point. We release information on how ACP is calculated, has anyone seen how their TDP is calculted? They probably don't want that to be known because too many people think that is max today. It really isn't. By a long stretch.

Zum Vergrößern anklicken....

JF schrieb:

We have said 2011, not early 2011. I have to be very careful with my words because I cannot indicate when in 2011 the product will launch.

EVT is 6 months prior to launch, generally speaking. I can't get into any other product team's schedules, but for servers it is 6 months. If EVT started we would be launching in Q3 2010, and that is NOT the case.

A wafer generally takes ~13 weeks from start to finish. Once you receive parts they go through several steps that I will not reveal, then they land in our labs. We do some things to them from a test/qual perspective, and then, when they pass a certain % of qualification they are deemed EVT and sent on to our major partners.

The challenge here is that I have to be careful about what I say. People start doing the math to figure out where we are in the cycle. I am guessing that the original comment was started in that manner. Someone was hoping I would say they were wrong and indicate WHY they could not have samples. With an understanding of the process one could figure out where we are. Which is why I have stuck to "can't be true" and have not said any more.

Zum Vergrößern anklicken....

JF schrieb:

No offense taken. It's just that I know silicon schedules. I know the milestones to ~ the end of 2011 at this point. I know Bulldozer schedules well and don't really care to know the follow on product's schedules because that is outside of my horizon.

The earliest silicon comes in with ~1-2 wafers worth of product. These are extremely valuable and have the highest security. A company is going to know exactly where every one of them is (early silicon is always locked away in a lab). They are all internal, they don't go to partners. Highest scrutiny.

When you get to EVT silicon, now, you are building ~1000 or so units. Could one or two get into the wrong hands? Sure. Do these go outside of the company? Yes.

EVT is generally ~6 months prior to launch. If I am launching in 2011, there is pretty good odds that I am not at EVT level silicon, right? So, IF I had silicon (not confirming or denying), it would be locked away in the highest security internal lab, only a few folks would have access to it, and it would all be accounted for. At that point it is critical that every single piece is either in a system, or a tester, not just laying around. People would notice one missing and it would be a big deal.

Yesterday I was in the power lab (watch for a video in the future) and there were plenty of Magny Cours laying around. I picked one up out of the tray for the video. That would never happen with Bulldozer. I doubt they would even let me in the lab, I have no business in there; pretty sure my badge wouldn't work

Zum Vergrößern anklicken....

JF-AMD schrieb:

Yes, if you look at strategies, it is pretty clear where we stand on the server side:

AMD - more physical cores, lower clock speeds, lower power, optimize across all power ranges
Intel - fewer physical cores with HT, highec clock speeds, higher power, optimized for idle instead of actual usage

There are pros and cons to each scenario. If you are doing virtualization, cloud computing, HPC or heavily threaded workloads, then you get much better results with AMD. If you have low utilization servers or poorly threaded applications, you get better results with Intel.

That is why, philosophically speaking, we believe we have an advantage for the future. We see threading increasing, utilization increasing and thread weight increasing. All of those point to an architecture that gives more discrete resources to each thread and optimizes for more concurrency and weight.

For those that believe HT is the way to go because you have less circuitry, they can't ever explain how software will be smart enough to deal with the concept of "heavy threads" and "light threads". In a perfect world you would want to have your 4 main processor threads handling all of your work and only go to an SMT thread when you needeed to kick off the 5th thread on that processor, but it rarely works that way.

Zum Vergrößern anklicken....

JF-AMD schrieb:

OK, let me clarify.

First, heavy vs. light threads is entirely a software driven scenario, not CPU-driven. Think about this. Let's say you are doing terminal emulation, updating a database table with a record that includes 4 fields, each of which has 10 characters. That update is a light thread. Then on another server, you are modeling seismic data, taking a 2 petabyte seismic map and breaking it into smaller chunks to analyze. Those could be heavy threads.

For utilization, that is dependent on the scheduler and the application. Virtualization and cloud computing are driving high utilization. Video rendering is high utilization. Email is spotty. At night and at lunch, low utilization. At 8AM and right after lunch, it is high utilization. Software design is driving towards higher utilization, not hardware. We just have to be ready for the higher utilization, mainly around power and thermals.

The problem with SMT is that you need scheduling to be a LOT smarter about how you utilize threads across an app. Let's say for simplicity's sake that you have a dual core with SMT. Now you have the following complex and simple requests coming through at once:

Complex
Simple
Complex
Complex
Simple
Simple

So, how do you handle this?

You obviously give the "real" core the complex instruction, then, do you give the second core the simple command or do you give it to SMT?

Then the third complex command goes to SMT, right? But wait, there is a simple command right behind it. Shouldn't you hold the complex command, throw the next simple command in to the SMT and then run the complex on the real core?

As you can see, it gets complex. And if you have commands that are dependent on other results, do you push a complex thread onto a fake core in order to get the results that a simple thread needs (and ultimately runs on a real core?)

The bottom line is that as long as you have a real and fake core, you spend too much time trying to match needs to threads and you end up with an unoptimized system.

Imagine a 4-way intersection with stop signs. It is much more efficient if you have nothing but cars going through, alternating. Then, throw in an 18-wheeler and all the timing goes straight to hell.

Zum Vergrößern anklicken....

JF schrieb:

I love seeing my slides

Yes, each bulldozer module will have 2 integer cores and a shared FPU. When you consider that 80-90% of the work is integer, this is a great way to keep the performance up and reduce power consumption.

For those that said HT was such a great technology because for 5% more die space they get a 10-20% performance bump, the word from our engineers is that adding a second integer core to each bulldozer module is ~5% silicon but nets ~80% performance uplift over a single integer core.

I have been saying for a long time that the HT tradeoff was not worth it, this is why.

You'll see bulldozer-based products with generally the same power and thermals that you see on today's products, but with significantly more throughput.

Zum Vergrößern anklicken....

I won't speak to dektop implementations, but I will say that if it was possible to use the same infrastructure for a new processor, we tend to go in that direction. However, we would not purposely limit a processor just to fit into an old architecture.

The key is long life of a platform, with a change at the right inflection point. We went to 1207 when the transition to DDR-2 went mainstream. We went to G34 with the (upcoming) transition to DDR-3 makes sense (for servers).

I met with a pretty large web hosting company the last time I was in california and they said point blank "thank you for staying with DDR-2 for now. DDR-3 is too hard to source and the price is all over the board. It's just not right for volume right now."

We could always move to new sockets quickly for new features, or we could always limit the architecture to keep jamming it into the old packages. But who wants a 12-core processor in a 1207 package with 2 memory channels?

It is a delicate balance, but we always (in my opinion) make the right choice. So trust us that if we move to a new socket, there are reasons for that. And if we stay with the old socket there are reasons for that as well - but we will not be limited just for compatibility because in the end, 90-95% of customers do not upgrade their platforms. This group may be in that 5% slice, but you have to keep a big picture view.

Zum Vergrößern anklicken....

It is a timing thing. The Maranello platform was developed first and our partners were well down the path with designs. The San Marino platform was added after, so obviously the designs would come out after Maranello.

Back in my Compaq days we used to have a phrase about the number of projects you can do at any one time. They would talk about how many "pigs you can fit in the snake". (Think of pigs as projects and the snake as a serial development process.)

They used to joke about there being too many pigs in the snake. We face the same challenges today. The snake isn't big enough for everyone to do two major new platform launches side by side because they rely on many of the same resources (validation, chipset, etc.)

Zum Vergrößern anklicken....

JF-AMD schrieb:

So, here is how schedules work (in servers).

We provide granularity different levels based on how far out from launch we are.

Today, for instance, we are giving partners a month level view of the Magny Cours launch (we do have a day selected, but we don't share that).

For Bulldozer we give a half year range.

For the generation beyond bulldozer, we give a year.

As we get closer to the date it goes from year to half to quarter to month to date. What tends to happen is we say something like "2H" and someone in the room hears July 1st and someone else hears December 31st. Then, when we go to quarter granularity, and we say Q4, the July 1st guy says "they've slipped to October" and the December 31st guy says "still on track".

The reason we give a wider granularity and then narrow it in is that there are more variables further out than there are as you get closer. Drove home from new orleans last week. When I got in the car the GPS said 9 hours, arriving at 6PM. When I was halfway through the trip, the GPS said 5:30 and when I was an hour out of Austin, it was saying 5:00.

As I got closer there were fewer variables and more was known about the past, allowing me to be more accurate about the final point.

Zum Vergrößern anklicken....

JF schrieb:

Of course I don't comments on dates or schedules. Even if the silicon is flawless (like Istanbul and round 2 of shangai), you still have to go through 3 rounds of testing by partners.

Imagine, for instance that each round of validaiton is a month and each tapeout to new silicon is 6 weeks.

Normal schedule:
Tape out to silicon: 6 weeks
Validation 1: 4 weeks
Tape out 2: 6 weeks
Validation 2: 4 weeks
Tape out 3: 6 weeks
Validation 3: 4 weeks

In this cycle you have 30 weeks from early tape out to finish of validation. Keep in mind that the tape out is not the "first" tapeout (that is for internal only) and I compressed the cycles for convenience - don't assume that when you hear tape out that you will see silicon in 30 weeks.

Now, if you had an istanbul-like pull in, you probably get something like this:

Tape out to silicon: 6 weeks
Validation 1: 4 weeks
Validation 2: 4 weeks
Validation 3: 4 weeks

Now you are at 18 weeks. Knowing we were able to pull in by 5 months shows that these numbers are really aggressive, but just for explanation. I didn't want to get into the actual project details. But the key is all the time you save is on tapeout to silicon (and associated handling/transport times), not on validation. Plus I did not show internal validation where we do cursory work before giving to partners.

Quelle

Zum Vergrößern anklicken....

JF schrieb:

Now we are in the grey area that I cannot comment on.

Let's just say that all of the comments above about this are wrong. Our cycle is generally about 12 months from tapeout to shipping, so we are very careful about publicly commenting on tapeout dates. But if we are about 12 months, then you should assume that a product available in 2011 would tape out in 2010, so statements about taping out already could generally be considered more inaccurate this early in the year.

Oh, and just so we are all clear, when we announce that we have taped out, keep in mind that I said "GENERALLY". There are more factors than just tape out date that will drive the actual introduction.

The good news is that the platforms are already ready based on where we are with G34 and C32. The bad news is that this is a brand new microarchitecture, so you have to expect that validation will be a big job this time around.

Zum Vergrößern anklicken....

JF schrieb:

This has been discussed many times. When you make a new product you generally build in 2 silicon spins, one major and one minor. Validation finds things and you need to correct them.

Shanghai had a major spin and no minor, so it was done quick. Istanbul had first rev ready for production so neither spin had to happen.

Bad planning? No, quite the opposite. You should never plan to get the silicon right the first time around, that rarely happens. I'd rather plan for the spins and not need them then not plan for them and have to slip your schedule.

Zum Vergrößern anklicken....

JF schrieb:

Tape out of products falls into a category that is generally governed by Regulation FD; it can be material to the business, so it has to be released in the proper forum as it is sensitive information.

It is not a question that we would answer in a web forum; typically, if we ever make a statement (and for many products in the past we have not indicated tape out), it comes from the CEO in either an analyst meeting or a earnings call. This is to ensure that we are following all financial regulations. I can think of 2 products that I am shipping right now where we never publicly stated any tape out info, so I recommend not tying a lot to the tape out statements.

Zum Vergrößern anklicken....

JF schrieb:

Engineering samples can be good or bad. We plan for 3 rounds of silicon, proto, EVT and DVT. Proto are the early ones, only a few hundred parts. Probably highly unlikely that you would come across one of those.

EVTs are usually in the low thousands, but typically only go to the largest OEM customers.

DVTs are a larger number of thousands, and these are supposed to be final silicon. Generally these are final silicon and usually there are no changes to final. If there is a change it is only one layer.

If you have a DVT part, then you are most likely OK, but there could be a functional problem that you only find out months from now. If you have an EVT or a proto, then there is a high probability that it has an issue. And overclocking will generally make those issues more probable.

Buyer beware.

Zum Vergrößern anklicken....

The general problem that I see in comparing architectures is that there are 2 general methodologies:

1. Run a few client-based programs that run almost completely out of cache or rely on video card configurations and then declare a "winner"

2. Actually figure out what you need and run your software with your data.

The "leapfrogging" happens in #2. As to synthetic benchmarks that do not reflect actual server loads (I am a server guy, I won't even attempt to say what happens on the client side), generally speaking, they are a waste of time on servers.

Typically I find that when people evaluate servers they are looking at the following:

1. Value - what am I going to spend, and what am I going to get for that. Top bin speed processors tend to garner ~1-5% of the total shipments. Why is this? Because the extra cost does not justify the performance. With 95%+ looking at something other than performance, it is a shame that so much of the time is spent focusing on performance in reviews. My guess is that this is mainly because numbers are easy to quantify and "value" becomes far more difficult.

2. Power - And not just because power is a cost. The server guys generally do not pay for power, that is facilities. Maybe they get hit with a charge. The real reason is that they are running out of power capacity in the data center. So they need to focus on getting more systems in under the same power budget. Not an easy thing to do. More performance at the same power level is very appealing.

3. Concurrency - How well does the system multi-task. Server workloads are almost always multi-threaded and there are plenty of things going on at any one second. This will only get worse.

4. Manageability - With a data center full of servers, IT folks spend most of their time dealing with software, not hardware. Hardware is robust, it doesn't generally present problems. How many system images, how often do you update drivers, what is the schedule, the cadence of new releases?

5. Virtualization - Most workloads are being virtualized today, so virtualization efficeincy will be critical. NOT virtualization performance. Customers have on average 5-10 VMs on a single server, with generally 4-8GB of memory per VM. Currently VMmark, the most used virtualization benchmark, shows configurations of 80-100 VMs per server with maybe 512MB-750MB of memory per VM. This is not realistic to determine performance.

If you look at where bulldozer will be in 2011, you'll see 16-core server processors optimized for power efficiency, concurrency and virtualization. And AMD has always been the value choice for processors and platforms.

If you can strip out the hype and get down to what really matters to a server customer, you find that the business is not about leapfrogging and not about raw benchmark performance, it is about who can drive the most efficiency and value in their products.

If you look at AMD today, you will see that. If you look at AMD in 2010 with Magny Cours and Lisbon you will continue to see that. And in 2011, when the bulldozer architecture is here (which plugs directly into the Magny Cours and Lisbon sockets) you see that we take the ideas of value and efficiency to new levels. Performance may ping-pong back and forth, but true value has been consistently on AMD's side. And I believe it will continue.

Zum Vergrößern anklicken....

• AMD PowerNow!™ Technology with Independent Dynamic Core Technology
  enables processors and cores to dynamically operate at lower power and lower frequencies, depending on usage.
• AMD CoolCore™ Technology can reduce processor energy consumption,
  by dynamically turning off sections of a processor when inactive.
• Dual Dynamic Power Management™, also commonly known as “split
  plane” technology, allows for independent voltage control between the cores and the memory controller.
• AMD Smart Fetch Technology can reduce power consumption by allowing
  idle cores to write the contents of their L1 and L2 caches to the shared L3 cache and enter a “halt” state.
• AMD PowerCap Manager allows setting a fixed limit on a server processor’s power consumption.
• C1e: A sleep state invoked when all processor cores are idle
  This feature can equate to a significant power savings in your datacenter depending on system configuration, when the Northbridge and HyperTransport™ technology links are powered down and cores are at idle.
• APML (Advanced Platform Management Link) Remote Power Management Interface (RPMI).
  Provides an interface for processor and Systems Management monitoring and controlling of system resources (in APML-enabled platforms); Comprised of the Remote Power Management Interface (RPMI) and the Precision Thermal Monitor
  P-state limits.
  
  Remote Power Management Interface (RPMI):
  

  • Ability to monitor and control platform power consumption via p-state limits
  • Access to processor identification and health

  
  Precision Thermal Monitor:
  

  • Provides accurate information about CPU thermals to closely monitor power/cooling and proactively alert the Base Management Controller (BMC)

  
  Early notification helps save time and money by providing intelligence that can be used to more effectively monitor power and thermals to optimize cooling solutions in an IT datacenter​
• AMD CoolSpeed Technology Reduces p-states when a temperature limit is reached
  • Server can continue to operate if processor’s thermal environment exceeds safe operational limits.
  • Offers platform providers the ability to safely reduce system fan speeds which helps deliver greater platform efficiency

• AMD Core Select gives users the ability to select, via the BIOS, the
  number of cores visible to software per CPU, a feature that can lower software
  licensing costs.