# AMD Bulldozer 8 core cpus and Gentoo/gcc/ potential

## wrc1944

I was eagerly awaiting the release of the new AMD Bulldozer Zambezi 8 core "FX" cpus, but all the hardware/performance/reviewing sites and forums are trashing it big time.

The problem seems to be that performance is outstanding with multi-threaded apps, even beating the intel i7-2600k flagship cpu.

However, with single-threaded apps it sucks badly, not even competing with the previous generation AMD x6 Thuban cores, and badly losing to even the 2500k intel in single threaded apps. Power consumption is also way too high. Even the price/performance comparison is losing, according to most reviews I've seen (hundreds).  There's enough of them to get a good idea of what the FX's are capable of- and the consensus is very disappointing, so far.  Nobody is recommending this long-awaited chip, as opposed to investing in an intel in the same price range- in fact, at this point most would recommend X6 thubans over any FX zambezi.

Basically, the Zambezi seems to be a server chip, being marketed as a "desktop/general purpose" cpu, but the initial reports really seem to argue this is not working at all.  The AMD zone and many other sites have long detailed technical discussions of all the details, pros and cons, regarding L1, L2, and L3 caching problems causing huge cache misses and having to re-fetch from the cache. Some are saying the entire arch is "completely broken" in this respect.

All that said, most of the above mentioned reviewing has apparently been done on Windows 7 systems, and no real mention of Linux systems, yet. There's talk that the windows scheduler has problems with the new zambezi arch, and that currently most common desktop software is really not optimized for multi-threads.

This brings me to my Gentoo (and Linux in general) questions:

Since in Gentoo we compile everything ourselves using gcc, and have scheduler/kernel/USE and cflag flag options, I'm wondering if the performance problems with single-thread apps might be less of a problem in Linux in general, and especially with Gentoo?  

I realize that just re-compiling an app not specifically coded by its creator for multi-thread probably can't be completely transformed by gcc and multi-thread kernel options/patches, but this type of thing was being mentioned as being potential but limited "fixes" for windows7 and the zambezi cpus.

I've always run AMD cpus, and am currently using the athlon II X4 640 propus core (basically a phenom II just without the L3 cache).  I've noticed that during long emerges all 4 cores are always pegged at 100% usage for the duration, which I assume means portage/emerge is highly designed for multi-threading.  

Anyone using or planning to get a new AMD FX cpu, and have any thoughts/experiences on all this?

I'd really like to know if recompiling actually makes any difference as regards to single thread vs. multi-thread behavior/performance.  In other words, would recompiling a linux app originally coded for single-thread but using march=native, USE="threads", and any kernel threading options/patches render the code more suited for the 8 core zambezi which has superb multi-thread performance, thus justifying getting a zambezi cpu instead of an X6 thuban, or simply forgetting AMD and moving to the intel Sandy/Ivy bridge i7-2600k platform.  Guess I could keep the Athlon II X4 and wait for the AMD "Piledriver" and hope the new arch problems are fixed then.   :Rolling Eyes: 

If I really thought running Linux and Gentoo on these cpus would perform better than what's being reported on Windows7, I'd probably get one, as I'm using Gentoo Linux 99% of the time anyway.

----------

## DaggyStyle

AMD decided to follow the "more core, better" notion, that is why single core performance sucks, today, most of the apps are in transition from single core to multi core.

basically, the bulldozer arch is more server oriented the desktop oriented, this gives them better performance in the server section with less price against intel's sb server, add to the fact that intel doesn't seems to be able to solve the chipset but in their servers (same one which they solved for the desktop), thus then are shipping diskless systems.

the bottom line is, what are your needs? if you can live with the crappy performance of the programs you need which aren't mt optimized, then got for bulldozer, if not, then either wait for programs to finish the transition, wait for newer AMD chips or got intel.

that my 0.02 cents.

answering your question, compilation method usually doesn't affects the way a single threaded app works, different compilers can affect it.

imho, if some dev doesn't plan to port his sw to mt, then it isn't worth while to use it.

also, I wouldn't trust much windows benchmarks, most of the programs are either compiled with icc or are intel oriented.

----------

## krinn

there's way too much things bad in that cpu gen:

- real too high power eaten

- real too high tdp (seriously who will use that as server except maybe real high server with dedicated cooling system, but you must be mad to use more than one cpu of that type with a fan system)

- real too weak performance, that cpu cannot even seriously manage to beat even other amd cpu !

- that's not real 8 cores, bullshit marketing : these are just 4 cores with a "name it as you wish : advanced, tweak, dirty..." HT clone

- the "windows is not ready for it" explain nearly made me pee in my pants : 

-->someone might build a scheduler that will be aware of the turbo problem and try to assign more tasks to one core instead of spliting them to more cores so the cores might get higher turbo benefits : but this tweak will not proof the arch concept is good, just that running a task on fewer cores made them run at higher clock speed, looks like amd discover more clock speed increase calc speed :p

(this could be improve by scheduler yes, and this will of course also improve corei7 class cpu that also could turbo their core speed when fewer are in use)

-->and because of the 2 units in one core if you gave a task that depend on another task amd guys expect the sheduler to gave them both at the same core because it will be done faster, yeah they expect the scheduler to be the magic guesser of what you are about to ask to your cpu.

This is a great feature, but this feature should be thread as it is: if it work a bonus, if not then you see the real power of each core and this should be the default value use to speak about that cpu power, just because the bonus won't happen that much.

What amd is trying to do would be like if intel says that any HT cpu using HT is showing its power, and when not using HT it's because of the scheduler/os/bad luck... and it underrate our cpus, not our fault.

- the price is a joke, and anyone bying that cpu will take a lost in a week, as the cpu prize will fall faster than light.

- when gcc will be aware of the cpu, it might be able to optimize more the branching of thread knowing cache size & cpu specs, but it will always be the scheduler task to assign them. So gcc impact will be low while you can expect random results with tasks assignations.

And as daggystyle said, comparing benchmark in windows programs that are nearly always build with icc compiler isn't a good thing to do vs intel cpu.

The more laughting part is that if you compare program build with icc vs another amd cpu, this time it's legit as both cpu will have the same arms to battle, and this show the bulldozer is more a shovel than anything.

Many people compare that arch with netburst arch that intel design for high clock speed and at end gave weak cpu perf, high tdp, caching missery (too low cache at first, then a big cache help a bit, but too much cache miss and long branching gave high latency ending in poor results).

It's a sad news as the new intel cpu will then get out at an even lower clock speed (yeah weaker perf so they will keep a big marge in perf in case amd start to trouble them later) and they will get out at a higher prize now

----------

## DaggyStyle

the intel i7 isn't a real 8 core too... most of intel's cpu are pseudo multi cores

----------

## <3

 *DaggyStyle wrote:*   

> the intel i7 isn't a real 8 core too... most of intel's cpu are pseudo multi cores

 

Yeah but Intel does not market it's virtual cores as a logical one. For Example a core i7-2600K is advertised as a quad core chip even though it has 4 logical cores and 4 virtual ones.

----------

## DaggyStyle

 *<3 wrote:*   

>  *DaggyStyle wrote:*   the intel i7 isn't a real 8 core too... most of intel's cpu are pseudo multi cores 
> 
> Yeah but Intel does not market it's virtual cores as a logical one. For Example a core i7-2600K is advertised as a quad core chip even though it has 4 logical cores and 4 virtual ones.

 

can you explain to me the diff between virtual core and logical core?

maybe Intel doesn't but Intel isn't selling the product to the customer, where I live, the i7 are advertised as 8 cores.

also, Intel did it with the first C2D, why can't AMD do that?

----------

## krinn

they didn't  :Smile: 

look at cpu specs from intel, they tell you the #cores and #threads, no lie (this time)

http://www.intel.com/content/www/us/en/processors/core/core-i7-processor/Corei7Specifications.html

----------

## DaggyStyle

 *krinn wrote:*   

> they didn't 
> 
> look at cpu specs from intel, they tell you the #cores and #threads, no lie (this time)
> 
> http://www.intel.com/content/www/us/en/processors/core/core-i7-processor/Corei7Specifications.html

 

I didn't said they lied this time, I said that vendors are selling i7 as octa-cores.

----------

## wrc1944

Perhaps a better way to ask the question might be:  Does anyone know which of the main Linux apps are coded for multi-thread, and which are not?

Apparently portage/emerge is multi-threaded at least up to 4 cores, as all of my 4 cores of my Athlon II X4 640 are always at a constant 95-100% usage when doing "emerge whatever."

Thus, so as far as Gentoo linux and all the compiling we do is concerned, the AMD FX Bulldozer 8 core might be an ideal system. 

In my case, in addition to the usual Office apps, web Browsers, and Multi-media apps, I'm particularly interested in knowing definitively if any of the  Linux pro audio apps like Rosegarden, Ardour, Audacity, Hydrogen, Qsynth, etc., etc. are indeed multithreaded. Anyone know, or know how to find out if any app is single or multi-threads?

That would definitely be a deciding factor in whether or not I'd buy a Bulldozer system right now, or maybe just drop in an on sale AMD Phenom II X6 1100T in my current AM3 system, and wait until Piledriver's out, where hopefully some of the Bulldozer problems will be revised/fixed.

----------

## DaggyStyle

 *wrc1944 wrote:*   

> Perhaps a better way to ask the question might be:  Does anyone know which of the main Linux apps are coded for multi-thread, and which are not?
> 
> Apparently portage/emerge is multi-threaded at least up to 4 cores, as all of my 4 cores of my Athlon II X4 640 are always at a constant 95-100% usage when doing "emerge whatever."
> 
> Thus, so as far as Gentoo linux and all the compiling we do is concerned, the AMD FX Bulldozer 8 core might be an ideal system. 
> ...

 

that is what I've said...

btw, I run gentoo with 8 cores so I can up the bar to 8 cores, I wanted to install gentoo at work but me boss doesn't allow my, shame, I wanted to see how gentoo behaves on a 104 cores, 0.5TB mem beast...

----------

## mattst88

 *wrc1944 wrote:*   

> Apparently portage/emerge is multi-threaded at least up to 4 cores, as all of my 4 cores of my Athlon II X4 640 are always at a constant 95-100% usage when doing "emerge whatever."

 

The process of compiling is very easily parallelizable since projects consists of a large number of independent C files, which can be compiled independently. It's not portage that's multithreaded, it's that make is able to invoke gcc multiple times, ie: make -j4.

----------

## krinn

 *mattst88 wrote:*   

>  *wrc1944 wrote:*   Apparently portage/emerge is multi-threaded at least up to 4 cores, as all of my 4 cores of my Athlon II X4 640 are always at a constant 95-100% usage when doing "emerge whatever." 
> 
> The process of compiling is very easily parallelizable since projects consists of a large number of independent C files, which can be compiled independently. It's not portage that's multithreaded, it's that make is able to invoke gcc multiple times, ie: make -j4.

 

It is because of --jobs that will spawn multiple make  :Smile: 

----------

## mattst88

 *krinn wrote:*   

>  *mattst88 wrote:*    *wrc1944 wrote:*   Apparently portage/emerge is multi-threaded at least up to 4 cores, as all of my 4 cores of my Athlon II X4 640 are always at a constant 95-100% usage when doing "emerge whatever." 
> 
> The process of compiling is very easily parallelizable since projects consists of a large number of independent C files, which can be compiled independently. It's not portage that's multithreaded, it's that make is able to invoke gcc multiple times, ie: make -j4. 
> 
> It is because of --jobs that will spawn multiple make 

 

That's true. I'd forgotten about --jobs.

----------

## Ant P.

You're better off waiting for a FX II model. The 1st-gen Phenoms sucked too. A Phenom II X6 T is the best value for money you can get from AMD for the time being.

----------

## Chiitoo

Well at least it's holding a world record (for now).  That must count for something, right?  Right?!

Anyhoo, I've been using a Phenom(tm) II X6 1090T for a little over a year now, and it's been serving me quite well and emerge will gladly use it so much (all cores at around 100% at certain points) that 2GiB of RAM is not enough for it with -j7 or even some lower, resulting into a grand slow-down, to a point where the screen is updates every 10-30 seconds or so, until the build fails or I manage to kill it otherwise.

I had to actually reduce it to around -j3 or 4 to prevent this when building some larger packages.

Why only 2GiB you ask? Well, one of the sticks went bad (used to have 4 in total), so I had to deal with that for a while.  Now I have 12GiB from which 8 is installed and all is well again.  ^^

Only thing annoying me about it is that the price dropped a LOT just a while after I bought it.  But then again, that tend sto happen me anyways, no matter when I buy stuff, so I'm used to it.  I think I will do fine with this for many more years to come.  Unless... I mean until I win lots from a lottery.

----------

## Anon-E-moose

The x6's are reasonably priced, and decent performance to them.

----------

## wrc1944

Thanks to all for the feedback!   :Smile: 

Here's a link I ran across for some new benchmarks of Bulldozer running with Gentoo, with more to come:  http://www.phoronix.com/scan.php?page=news_item&px=MTAwMTg

For example, the FX-8150 on Gentoo, with gcc-4.6.1, kernel 3.0.6-gentoo: http://openbenchmarking.org/result/1110168-GR-BULLDOZER88

Guess I'll try running the Phoronix Test Suite on my current athlon II  x4 640, and see how that compares to the 1100T x6 and Bulldozer 8150/8120.

Main AMDzone Bulldozer thread-  lots of new feedback coming in now.

http://www.amdzone.com/phpbb3/viewforum.php?f=532&sid=4aa5c037b946489a74cbb488dd4e9fa1

Newegg has some more Bulldozer user's real-world reviews now trickling in (58 so far).  

http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100007671%20600213781&IsNodeId=1&name=Socket%20AM3%2b

Also, FWIW a good 3 page thread with early discussions of tech details of Bulldozer/Linux from March 2011. I thought it was worth a look for more background.

I really need to do my homework and wait for some more real-world user results before making any decision.

http://www.amdzone.com/phpbb3/viewtopic.php?f=532&t=138486

----------

## Dominique_71

 *wrc1944 wrote:*   

> In my case, in addition to the usual Office apps, web Browsers, and Multi-media apps, I'm particularly interested in knowing definitively if any of the  Linux pro audio apps like Rosegarden, Ardour, Audacity, Hydrogen, Qsynth, etc., etc. are indeed multithreaded. Anyone know, or know how to find out if any app is single or multi-threads?

 

All the Linux pro audio apps are using jack as sound server. A requirement for a good audio app, and especially with a real time sound server like JACK, is multihreading. The audio thread must be separated from the control thread. You will also get a GUI thread, and so on. The consequence is than the audio pro apps are all multithreaded. Even one of the oldest audio app, the alsaplayer, is heavily multithreaded.

----------

## wrc1944

Dominique_71,

Thanks very much for the info!   :Very Happy: 

This is very encouraging regarding the Bulldozer FX cpus, as audio app performance is one of my main criteria.  

This, with Bulldozers apparently being superb with multi-threaded apps, and the Gentoo/gcc compiling process apparently utilizing all cores, things are looking a little better for my specific usage patterns.  Especially since I always compile/patch all my own kernels, even in other binary distros.  Could anyone point me towards more info on the topic of audio apps being multi-threaded?

I'd think that even with the lack-luster single thread bulldozer performance, with web browsers, email, and normal office apps bulldozer would still offer "cpu overkill" performance.  Not sure on other multimedia and/or xorg/video app performance (being single or multi threaded?).

Anyone with a Bulldozer running any Linux audio apps, such as multi-tasking with for example Rosegarden/Ardour/Jack along with multiple soft-synths and multiple VST instruments, soundfonts, and effects?  Sure would be nice to get some user feedback on this audio usage pattern using Bulldozer.

UPDATE:  GCC 4.5 vs. 4.6 On AMD's FX-4100 Bulldozer, Published on October 20, 2011.

http://www.phoronix.com/scan.php?page=article&item=amd_fx4100_gcc&num=1

From end of P.5, the basic conclusion, but the individual tests are still worth a look- some are significantly better with gcc-4.6.1, but it is a mixed bag.   :Rolling Eyes:   However, as is mentioned, this is with the stock compiler flags.

 *Quote:*   

> More Bulldozer Linux benchmarks are on the way now that there's the AMD FX-8150 at hand for benchmarking, but as these benchmarks show, simply upgrading from GCC 4.5 to GCC 4.6 won't yield any real improvements for the new AMD processors when using the stock compiler flags. Some tuned compiler tests, a look at AVX on Bulldozer, and other articles are among what's coming up for the FX-8150 system.

 

----------

## wrc1944

I'm currently wondering how the Con Kolivas BFS scheduler might behave (positively or negatively) with the Bulldozers as opposed to stock kernel versions, as regards to its current issues. 

Here's the latest version, where the concepts are explained in detail (commented out in the patch itself) in segments like Goals, Design summary, Design reasoning, Design details, Task insertion, Data protection, Virtual deadline, Task lookup, Scalability, etc.  Seems like these items might have some effect on what people are discussing about Bulldozer issues, or is this unlikely to make any difference at all?

http://ck.kolivas.org/patches/bfs/3.0.0/3.0-sched-bfs-413.patch

I'm a long-time user of the Kolivas desktop responsiveness patches, but certainly no expert, but over the years they have always seemed to perform pretty well compared to stock cfq or deadline sinmce the earliest kernel 2.6 days.

Maybe someone with a lot more knowledge than I have would like to take a look at this, and offer comments and/or opinions?

----------

## Atle

I think too much emphasis is put on "single threaded apps". How often do you sit and wait for one of those? How often is the CPU the bottle neck here? Me: never.

Even web browsers (at least Google Chrome) are multithreaded these days. And common usage for me is running several programs at once. At the moment, Windows XP in VirtualBox, Chrome, Firefox (two different users), Android emulator etc. Cores and RAM are for me more important than really fast cores.

A quick google seems to indicate this CPU draws 125W, which is in the same range as Intel Core i7 which seems to be common at 95W or 130W. (You can get low power 65W i7 soon).

It really comes down to how you use your computer. If you're playing games on Windows, I'd go for fewer faster cores. If low power consumption is important I'd go for i5 or i7 65W. If you run a server, many virtual machines, many browsers etc., the new Bulldozer seems like a strong choice to me.

----------

## John R. Graham

Split off nontechnical conversation and moved it to Intel processors are manufactured into the Zionist country in Off the Wall.

- John

----------

## drescherjm

 *Quote:*   

> I think too much emphasis is put on "single threaded apps". How often do you sit and wait for one of those? 

 

Every single day of my life for the last 30+ years. Well almost..

 *Quote:*   

> How often is the CPU the bottle neck here? Me: never. 

 

Even my 12 threaded i7 processor with 18GB of memory is a bottleneck at what I do at work.

----------

## wrc1944

I finally decided to order a x6 1090T from newegg.

With a revised AMD Bulldozer version and/or Ivy Bridge chips probably released within 6 months or so, I just couldn't justify getting any of the current Bulldozers plus a new motherboard that would likely be replaced so soon. All things considered, a simple x6 1090T drop-in replacement into my current 8GB ram system seemed the best option, and wait and see what Q2/Q3 2012 brings.  

I'll admit the 8-core Bulldozers were very tempting (especially for Gentoo emerging), but reading many hundreds of user and website reviews on the x6 1090T vs. Bulldozers convinced me I easily could live with the x6, and save most of my money for a future "Bulldozer II/Piledriver" or Ivy Bridge setup on a future upgraded motherboard/cpu combo that had the bugs worked out.  Plus, later on, I'll still have a great x6 system for my backup box.

FWIW:  Here's a thread just started on AMDzone "Recommended compiler optimizations for Zambezi and Interlago"  Has 2 links (from amd devs) for gcc-4.6.x and Open64 compilers, that mention things like -ftree-vectorize, avx flags, and march=bdver1 (interlagos), among others.

http://www.amdzone.com/phpbb3/viewtopic.php?f=532&t=138898

----------

## wrc1944

New 13 pages of in depth Bulldozer FX-8150 benchmarking on Linux.  (Unfortunately, on Ubuntu and not Gentoo, but still good stuff). 

http://www.phoronix.com/scan.php?page=article&item=amd_fx8150_bulldozer&num=1

Quote from the last page, which is encouraging:  *Quote:*   

> Fortunately, for Linux users, most open-source software is well multi-threaded. If you are running Gentoo, Arch, or just doing a lot of compiling in general, the AMD Bulldozer CPUs should be able to prove their value very well. Beyond that, with open-source software that you may be building, GCC and Open64 already have Bulldozer (version 1) optimizations in place.
> 
> Linux users will be able to take full advantage of the Bulldozer architecture sooner than Microsoft Windows customers, which will primarily see the real potential when Windows 8 is released. In the Linux world, there's still some Bulldozer kernel work that's not yet merged and presumably more compiler/kernel optimizations coming, but we will hopefully see all of that merged and ready in time for next spring when Ubuntu 12.04 LTS, Fedora 17, and other Linux distributions are pushing out their new versions. If you are so inclined, you can always pull the patches yourself, tune your compiler options, and make other tweaks today to take greater advantage of these new AMD processors. The upcoming FX-8150 Linux articles have more revealing information.

 

----------

## dE_logics

As I said, AMD sucks.

----------

## depontius

 *dE_logics wrote:*   

> As I said, AMD sucks.

 

If not for AMD, we'd all be running 32-bit NetBurst on affordable PCs and 64-bit Itanium on high-end machines.

Competition is necessary for any marketplace.  The real sin here is that Intel twisted arms to prevent K8 from getting the success it deserved.  The real fallout was that it gutted AMDs ability to afford proper development efforts and continue effective competition.

----------

## krinn

 *depontius wrote:*   

> and 64-bit Itanium on high-end machines.

 

But on the other hand, people vomit on the itanium serie when they came out because they weren't 32bits and not using x86 code, so emulation was the path to have a 32bits x86 program running.

But the IA64 arch is more than good, and was design with full 64bits in mind, while the x86-64 was design with "keep it x86" in mind. Even intel now slowly make the itanium evolve because the public reject the lost of x86, lookout the 500 top computers, you will find some in the top list running itanium cpu.

We cannot really tell, but without x86-64 maybe itanium would have win the match, and our computers would be full 64bits (and not a dirty hacked 32bits cpu with 2-3 more registers and a hell slow access to memory)

Now considering the next step will be virtualization, itanium would have certainly be a real better choice for a nextgen pc.

As you see, we cannot really guess what would have been our present without amd  :Smile: 

When intel was in pain and amd was on top with not only real better arch, real better cpu, but also cheaper ! AMD guys should have invest far more in cpu than buying that ati crap cards drivers maker ! (ps: read it again, never said ati cards are shit, but their drivers are so shitty that i'm thinking it's not by mistake but a wanted feature !). IMO bad move.

----------

## depontius

True, IA64 is a true 64-bit architecture, but really amd64 isn't bad, either.  My problem with IA64 is that it was as much designed by patent attorneys as it was by engineers.  The real design point of IA64 was to avoid getting cloned.  They picked an academic design point, VLIW, at least in part because it hadn't been implemented in commercial hardware, and therefore had little in the way of patent protection.  Then they formed a separate NPO (non-practicing organization) company to hold the patents, which then licensed the patents back to Intel and HP.  They did it this way to eliminate the need for any cross-licensing considerations, since NPOs don't have to worry about that kind of thing.  Intel and HP do have to worry about cross-licensing, but since they're only IA64 licensees, they "can't" cross-license IA64.

It was designed to be a monopoly, from the get-go.

You get to the other fact-iod - VLIW.  Sure they badged a new acronym, EPIC, but it's essentially VLIW.  VLIW was predicated on the idea that compilers can do a better job of parallel scheduling than hardware.  That hasn't turned out to be particularly true - or as a friend told me decades back, after coming back from SigGraph, "Hardware is easy, and Software is Hard."  Many, many interesting developments have turned up in parallel hardware scheduling, many of them from Intel, even.

IA64 came out looking like a dog, though I'll agree that more modern incarnations perform much better.  Ironically, one of the ways they have picked up their performance has been to add some of the more modern x86 hardware parallelism tricks.  It's less pure VLIW, less pure EPIC, than it started out.  I guess that's better, but I'm still very unhappy with its origins.

NetBurst started with Market-droids wish for higher clockspeeds, Itanic started with their wish for a monopoly architecture.  Software and hardware engineering were in the back seat for both.  That rubs me the wrong way.

----------

## DaggyStyle

 *dE_logics wrote:*   

> As I said, AMD sucks.

 

in the server department, interlagos is outperforming sb in almost every department and intel is shipping boxes without hd in it due to a chipset bug which they solved for desktop but not for server, so unfortunately for you, AMd doesn't sucks.

----------

## Anon-E-moose

I don't care about the holy war of amd vs intel.

I've bought amd for over a decade now and for me, it's about bang for the buck.

----------

## depontius

I'll agree, it's about bang for the buck.

I'm not an AMD/Intel fanbois into the CPU wars.  I just have a longer term perspective on "bang for the buck", and know that without competition, thinking "bang for the buck" right now will turn out to be short term only.

I'm also an engineer, with enough years in the industry to know how easily marketdroids can get decision preference over good engineering.  I dislike that, whether it's AMD or Intel.  (or Apple, or Microsoft, etc, etc, etc.)  Oh yeah, and I also believe the the Free Market needs a little nurture and control in order to remain Free.  Whatever his other problems or idiocies, not everything Karl Marx said was wrong.

----------

## dE_logics

 *depontius wrote:*   

>  *dE_logics wrote:*   As I said, AMD sucks. 
> 
> If not for AMD, we'd all be running 32-bit NetBurst on affordable PCs and 64-bit Itanium on high-end machines.
> 
> Competition is necessary for any marketplace.  The real sin here is that Intel twisted arms to prevent K8 from getting the success it deserved.  The real fallout was that it gutted AMDs ability to afford proper development efforts and continue effective competition.

 

I know that, but AMD has started to suck and so it's market share is reducing. I still have an AMD turon laptop which has a broken virtualization feature.

----------

## wcg

This seems to be targeted well beyond the desktop and a bit new

for gcc -march=native to have caught up with it.

A good in-depth article on the cpu architecture:

http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=1

A branching gcc mailing list thread that discusses the difficulties of optimizing for a cpu

architecture this complex:

http://gcc.gnu.org/ml/gcc/2010-06/msg00405.html

----------

## piwacet

Here's an interesting article presenting some tests of OS scheduling strategies for bulldozer (on windows 7):

http://techreport.com/articles.x/21865

----------

## Ant P.

 *Anon-E-moose wrote:*   

> I don't care about the holy war of amd vs intel.
> 
> I've bought amd for over a decade now and for me, it's about bang for the buck.

 

I'll still buy AMD even if they lose that advantage. I refuse to play Intel's feature set russian roulette after being burned three times in a row.

----------

## 3Miro

So far I do care about the Intel/AMD war, mainly because it has been totally one sided win. The winner is clearly ME.

I find this thread very interesting as I am looking into buying a new machine in the next few months and I would want it to be as powerful as possible.

Currently I have a Phenom II X6 3.2Ghz Desktop and a System76 i7-2670QM Laptop. Now which CPU is better .... well it depends. I am doing the test on the only app that really matters, those are my programs (Scientific Computing). I couldn't care less on what benchmark results are, I only care about the apps that do matter for me.

When I go single threaded, then Intel is between 30%-50% faster.

However, the shocker is when I use OpenMP and make a fully parallel program utilizing all the cores/threads (6 vs  :Cool: . The the tables flip completely and it is AMD that wins by 30%-50%.

The Intel has the i7-2600 and i7-9xx series that will probably win against Phenom II on multi-threading, it is just that they cost a lot more, so this has to also be taken into consideration.

From what I read, Bulldozer is more of the same. Bad single thread power for real multi-thread power. The other question is whether or not one really needs that much single thread power, other then Adobe Flash (which is just an example of poorly written software), I don't really have any single thread app that challenges either CPU.

----------

## wrc1944

GCC-4.6.2 just released. http://gcc.gnu.org

http://www.phoronix.com/scan.php?page=news_item&px=MTAwNjc

and for the changes:  http://gcc.gnu.org/gcc-4.6/changes.html

Here's a brief quote. Although it mentions Bobcat cores specifically, it also mentions "the new -fsplit-stack option permits programs to use a discontiguous stack. This is useful for threaded programs, in that it is no longer necessary to specify the maximum stack size when creating a thread. This feature is currently only implemented for 32-bit and 64-bit x86 GNU/Linux targets."  

Seems like it might apply to the topic, and offer some improvements to Bulldozer for us Gentoo users.  One can hope.....  

BTW, what is this "AMD's BMI (Bit Manipulation)" stuff- I never heard of it?

 *Quote:*   

> New Targets and Target Specific Improvements
> 
> IA-32/x86-64
> 
>     The new -fsplit-stack option permits programs to use a discontiguous stack. This is useful for threaded programs, in that it is no longer necessary to specify the maximum stack size when creating a thread. This feature is currently only implemented for 32-bit and 64-bit x86 GNU/Linux targets.
> ...

 

----------

## Thomas2010

How difficult would it be for either Intel or AMD to ditch 32-bit support and make a pure 64-bit processor? The main problem I saw with Itanium when it came out was that for the average home user, it was not realistic because Windows, all of its utilities, and all the applications people used would have to be compiled as 64-bit. For servers, it made sense because the number of applications that would have to be made 64-bit was very small, as well as, server applications would make use of 64-bit hardware.

If 32-bit support was removed, what benefits would there be?

----------

## Ant P.

By "removing 32-bit support", do you mean making a chip that can't run a BIOS, EFI, bootloader or Linux kernel while retaining full AMD64 compatibility, which includes the entire 32-bit ISA anyway — or do you mean they should --funroll-loops their CPU business and throw away their entire market for a 2% speedup?

----------

## 3Miro

 *Thomas2010 wrote:*   

> How difficult would it be for either Intel or AMD to ditch 32-bit support and make a pure 64-bit processor? The main problem I saw with Itanium when it came out was that for the average home user, it was not realistic because Windows, all of its utilities, and all the applications people used would have to be compiled as 64-bit. For servers, it made sense because the number of applications that would have to be made 64-bit was very small, as well as, server applications would make use of 64-bit hardware.
> 
> If 32-bit support was removed, what benefits would there be?

 

This is not realistic. With Gentoo we get to compile our apps for whatever CPU/Architecture we have. Other Linux distros often come with full 64-bit repositories, but once you get outside of the FOSS or Linux, things are quite different. Only last month did Adobe release 64-bit Flash, Adobe Reader for Linux is 32-bit only. Most modern machines sell with 64-bit Windows, however, all computer games are 32-bit. Companies that distribute pre-compiled/closed binaries, distribute mostly 32-bit software. Unless the market changes, Intel and AMD will keep full 32-bit compatibility.

----------

## DaggyStyle

 *Thomas2010 wrote:*   

> How difficult would it be for either Intel or AMD to ditch 32-bit support and make a pure 64-bit processor? The main problem I saw with Itanium when it came out was that for the average home user, it was not realistic because Windows, all of its utilities, and all the applications people used would have to be compiled as 64-bit. For servers, it made sense because the number of applications that would have to be made 64-bit was very small, as well as, server applications would make use of 64-bit hardware.
> 
> If 32-bit support was removed, what benefits would there be?

 

just a side note, theoretically if 32 bit support will be dropped, than Intel are in big problems as they own the rights for 32 bit while AMD own the rights for 64 bit...

----------

## wcg

So will there be a USE flag for enabling frame-pointers by default in the gcc ebuild?

(Meaning build with frame pointers unless -fomit-frame-pointer is in CFLAGS, same

as it is now with current stable and testing gcc versions.)

----------

## Thomas2010

 *3Miro wrote:*   

> This is not realistic. With Gentoo we get to compile our apps for whatever CPU/Architecture we have. Other Linux distros often come with full 64-bit repositories, but once you get outside of the FOSS or Linux, things are quite different. Only last month did Adobe release 64-bit Flash, Adobe Reader for Linux is 32-bit only. Most modern machines sell with 64-bit Windows, however, all computer games are 32-bit. Companies that distribute pre-compiled/closed binaries, distribute mostly 32-bit software. Unless the market changes, Intel and AMD will keep full 32-bit compatibility.

 

I was not thinking clearly. I was not expecting AMD and Intel to stop making CPUs with 32-bit support, but I did think a 64-bit-only processor would be better, somehow. Even if it was, I doubt there would be enough buyers to justify their production.

----------

## depontius

Actually, at some point it wouldn't surprise me to see 32-bit compatibility boxed off on its own, and the main chip be 64-bit only.  So far 32-bit and 64-bit haven't driven inconsistent directions, so there hasn't been pressure to do this.  This too may pass.  We're getting to have so much silicon available that we could almost afford to separate out an i686-class CPU, just for backward compatibility.  The other requirement is that the bulk of the needs truly be 64-bit, so that the 32-bit side wouldn't need top-notch performance.

----------

