Is it possible that having an unknown CPUID simply means its not optimized for a CPU it doesn't recognize so it defaults or uses the best instruction sets for compatibility instead of performance with proper instruction sets?
Now if I tell a program that is is working with one CPU instead of the other and I am using the same CPU for all it does make a difference as it pertains to registers and system calls does it not?
Perhaps I am missing something here but to tell a program that an Intel is and AMD and an AMD is an Intel is not a legitimate test because they are different. Registers are not the same and how the program approaches functions would differ would they not? I see what you are doing but I just do not see it working out the way you plan.
And let us not forget the AVX instructions in which AMD FX cpus have tested slower on. The fact is Intel made the compiler for Intel chips. So unless your chip is exactly the same as an Intel chip you will not bench the same as in intel chip. As far as I know the clones stopped with i486.
I think the thing to do if you really want to see what is going on is get benchmarks from the days when AMD was ruling the roost. If the Intel's come out with a lead that matches modern testing software percentages then the testing being done here is just an exercise and nothing more.
You know I actually went through all of this in a GD thread a few years back. Intel compilers are for Intel processors. It is like saying the PhysX should run on AMD cards. Nobody is forcing software vendors to use the Intel Compiler.
EDIT: Drive rapid development and winning performance with these suites of compilers and performance libraries
Intel® Professional Edition Compilers include advanced optimization features, multithreading capabilities, and support for Intel® processors and compatible processors. They also provide highly optimized performance libraries for creating multithreaded applications.
IMHO that little string makes all the difference in the world. CPUID. How do I send these commands. If Genuine Intel then Optimized if not then generic because I am not going to engineer my software for everyone else's CPU if they cant get it right.
Just a conclusion for me. It will look slightly different when I post it with my conclusions and opinions at the end of the first post. Think of it kind of like looking at someone's notes before they posted the data and wrote the report.
BINGO. That is what I was getting at from the get go.
IMHO that little string makes all the difference in the world. CPUID. How do I send these commands. If Genuine Intel then Optimized if not then generic because I am not going to engineer my software for everyone else's CPU if they cant get it right.
Okay, I'll bite. Then if you're Intel why would you write a compiler that uses optimizations, tell everyone it's compatible with "non-intel" CPU's and then have your compiler insert code that doesn't check for compatibility (which is very very easy to do) but instead checks for vendor name and then run the slowest code path possible? The "compatible" CPU is STILL fully capable of running SSE, SSE2, AVX etc. you just refuse to allow the other CPU's to run it. How is that quote "because I am not going to engineer my software for everyone else's CPU if they cant get it right."? Oh and don't forget that you didn't tell software developers using your software that your program does that because you know full well that they would not use your compiler if they knew that a large number of their "customers" would not be able to run their software the way it was intended to run. In fact the Intel went about it in such a convoluted way that they shot themselves in the foot and it will discriminate against "future" Intel CPU's which is why they had to come up with a hardware work-around so they didn't nail their own CPU's as well. Yet as a "programmer" you patch the Intel compiler to disable the CPU dispatcher" as agner shows how to do on his blog and not only does it THEN check for compatibility (because remember AFTER it passes the vendor ID name check it then checks for the instruction set compatibility flags) but it compiles code that runs just fine on any Intel or "Intel Compatible" (i.e. AMD, Via etc.). Hmm.... Do you honestly think that Intel with all of their money just rolled over and settled with AMD and FTC without a fight just because? Do you really think the European Union gave them the largest anti-trust fine in EU history (which included all of their practices including the compiler) just because?
We can all keep digging to find out why. The purpose of this thread is to see the "data sets" (which in themselves are facts just not the "facts" as to what is causing it) and then we can all dig around and get programmers and others to investigate and find out the exact causes and why's. But nobody is going to try to find out "why" there is a problem if they don't know there's a problem to begin with.
As for Archer, before we get back into the argument over Intel's compiler, let's make sure we find out 100% that it's the cause of it (I suspect it is but it's still just an educated guess).
Okay, I'll bite. Then if you're Intel why would you write a compiler that uses optimizations, tell everyone it's compatible with "non-intel" CPU's and then have your compiler insert code that doesn't check for compatibility (which is very very easy to do) but instead checks for vendor name and then run the slowest code path possible? The "compatible" CPU is STILL fully capable of running SSE, SSE2, AVX etc. you just refuse to allow the other CPU's to run it. How is that quote "because I am not going to engineer my software for everyone else's CPU if they cant get it right."? Oh and don't forget that you didn't tell software developers using your software that your program does that because you know full well that they would not use your compiler if they knew that a large number of their "customers" would not be able to run their software the way it was intended to run. In fact the Intel went about it in such a convoluted way that they shot themselves in the foot and it will discriminate against "future" Intel CPU's which is why they had to come up with a hardware work-around so they didn't nail their own CPU's as well. Yet as a "programmer" you patch the Intel compiler to disable the CPU dispatcher" as agner shows how to do on his blog and not only does it THEN check for compatibility (because remember AFTER it passes the vendor ID name check it then checks for the instruction set compatibility flags) but it compiles code that runs just fine on any Intel or "Intel Compatible" (i.e. AMD, Via etc.). Hmm.... Do you honestly think that Intel with all of their money just rolled over and settled with AMD and FTC without a fight just because? Do you really think the European Union gave them the largest anti-trust fine in EU history (which included all of their practices including the compiler) just because?
May or may not work Hint Hint. It may not work but it is compatible with other processors from competing vendors; it is optimized for ours. We can not take our time to change and edit and optimize our compiler for other manufacturers who may not have followed our exact schematics and our exact caching design and furthermore we can not be held liable for a competitors incompetence where designing paths and registers to our specifications are concerned. We will allow a generic code to run if it runs at all. We know it is going to work on our CPU so recognition of intel in the CPUID will optimize our code. If not Intel then the best code will run but it is not optimized. We have better things to do than reverse engineer our competitors processors to write optimized code for them.
EDIT: The caches alone cause some issues (L1 instruction cache mainly) and the L3 on Ph & PhII sucked as I have noted many times. The Athlon, AthlonII and even the Sempron were better processors.
We can all keep digging to find out why. The purpose of this thread is to see the "data sets" (which in themselves are facts just not the "facts" as to what is causing it) and then we can all dig around and get programmers and others to investigate and find out the exact causes and why's. But nobody is going to try to find out "why" there is a problem if they don't know there's a problem to begin with.
As for Archer, before we get back into the argument over Intel's compiler, let's make sure we find out 100% that it's the cause of it (I suspect it is but it's still just an educated guess).
I get it BH. you are just not good at debating like ED and arch are.
(Props to you guys for reals though cuz I see your points too I still think he is on to something.. and well.. so did the FTC at/during a right wing government yes?)
I do not want to bring politics into this except that it totally a part of corporations rights.
I am no wing. I was a libertarian however that was long after unions (against) and long before the rise of the megacorp (also against). I am not a left wing since I am against government handouts for people that do not work. I am not a right wing because I am against government handouts for people that force people out of work. (Oh..I mean support companies that fire 50 year old management and hire 2x the teenage stock boys and call it "job growth")
You don't get to be a billion company because you refused to step on some backs (or heads) to get there. Not Microsoft, not Intel hell not even Apple. They ***** about people stealing their ideas. They stole EVERYONE one of theirs.
You know they sued cuz nexus 3 had rounded corners? Waht the hell is that thing wit hthe yellow dipstick over it.
1987 Apple. Stop stealing **** Apple. (notice the name of the image? Insidepad, or ipad. WTF.I didnt do that BTW )
Oh snap I think I see a couple of gameboys in their as well. I bet rodenberry is rolling over in his GRAVE that people are fighting IP (let alone fighting) over designs that his franchise brought about before it happened.
Did intel "unduly influence the market to gain favor" yes thats been proven. Is it ongoing. According to angers it is. Do we have the ability to test it? Yes I think we do. HOWEVER including software benchmarks that are NOT vendor ID string dependent like cinebench is important as well, Not only for parity, but to show hey. Cinebench is not biased. Its just better on intel. how cinebanch works It is up to you to prove your point, you can google everything they talk about. Is it BIASED? Its built on others work so ...probably not. Run only the Open GL test then? Without a GPU capable its all CPU based anyway.
Looking forward to ALL your results. I just have one recommendation ditch the ones that also call on the DLLs that force an actual ID string like AIDA. So Everest, Sissoft. orobably PCmarks as well.
We are talking about CPU functions anyway. So some simple single and multithreaded apps are enough
Use an open notepad on your screen shots to differentiate VID strings not CPUz because it might screw up the software.
You have to show programs that are not intel biased
A) so people know
B) to prove your theory correct
But more than that I also agree with ED and Kev that optimizations are not wrong. What is the difference? there is one, and can you show it? I do not think you can to be honest I think it requires a company or government to show it. Governemnet did find it and "supposedly" shut Intel down on it.
The FTC’s proceedings against Intel in December were important for a number of reasons. Among them, the part concerning compilers is the least known by the general public.
It focuses on optimization and makes it seem like it wont run on AMD because they do not support the licensed extension that they received from Intel
That is the rub
You guys talk about "it dont work the same"
Super pi works on Linux
We arent talking RISC to CISC we are talking about LICENSED extensions. Not the same thing? WTF?
AMD adopted SSE2 in what 2001? Hit SSE3 about 6 months later? Venice?
I agree with BH, and I agree with ED/Arch.
Ed ARch optimizations are okay to do. In fact in racing (inevitable car analogy) shouldnt ferrari be able to adjust some camber and toe on their car, change drag coefficient and fuel for the track being run?
@BH. If BMW were given the same fuel woudl they be able to devleop a car they could camber/toe and aero fold into the track as well as intel. No. AMD hedged their money on FLOPS thinking it is what Intel was going for, and Intels inside man went FMA4? heh heh ( oh we are not even going to implement FMA3 fully since like DX10-11 many of hte features carry over.
Nut punch
Things have evolved less slowly technically than Shadowrun said I think, and of course no rise of ACTUAL trolls in 2012.. snicker, well im interested to see how that works out into the story. They guys at FASA wrote the history in the 80s up through 2050 and have been pretty much right so far
I will find a pic of TNG walking around with thin tablets if I have to go through my library!!
Oh also Shadow run talked about Wrist computers that leveraged the power of cyberspace. And connecting directly to PCs via cybernetic implants so a PC connection was just a ajack away. Your "super computer" was only as much cloud as you could afford.
Which is why I had my idea for the last 10+ years to build a super server for the home. One that could handle all your immediate requests, but out in the world as well. What was I intending to power it on? Intel oh but then I learned they cut features from their stuff. So AMD!!!
Future tech written almost 30 years ago, is happening now. Minus the UGE. (well we do have a lot of trolls on the internet I sometimes express myself that way as well maybe I am an Orc. lol)
Ipad is a fat piece of junk,, according to early 1990 standards...Same unit showed in the late 80s.. but you get the drift. Size and shape is what Apple is suing over now...
I'm running an array of programs including cinebench. The only thing I'm debating is whether or not to include the results screenshots for the programs that show the same results no matter what the CPUID vendor string is. Although if people are going to question the results then I guess I'll be forced to. Just sucks a little bit. I'm already going to be posting tons of pics for the triple runs on the programs with suspicious or outright huge deviations in results. Take Aida for example. the Intel runs as well as bubba hotep have 24 screenshots EACH since I had to do each test seperately (the "report" locking up because of the mem test is the culprit in that one). I'll be sucking up some bandwidth with this thread for sure LOL.
Oh, I did a preliminary run of wprime (quick run without saving anything) and the results were all the same which is completely expected since it's not using any optimizations (SSE etc.). I'll run it again probably tomorrow and save the screenshots.
Second, as for "Bias"...well I guess that's debateable. Maybe "reliability" is a better term, I don't know. IMHO any synthetic benchmark or even "real world" program that ignores the compatibility flags embedded in the CPUID and instead uses the manufacturers name to determine which code to run is unreliable and in some ways "Biased". What does a program care if the name is "AuthenticAMD", "genuineIntel" or "Timbuktu"? The information needed to run ANY type of code is contained within the CPUID. http://developer.amd.com/documentation/articles/pages/4292005119.aspx
While the hardware specifications and interfaces of those x86-compatible chips vary, along with power consumption and performance characteristics, they all conform to the core x86 instruction-set standards. Many also offer extensions to that x86 architecture, and many of those extensions have been implemented by several vendors. This means binary portability. Compilers written for one x86 processor should create object code and binaries that run on any contemporary x86 processors with those same extensions. The use of standards provides economy of scale, gives customers choices, and fosters innovation on implementation of those standards.
To Earthdog, maybe when I'm finished we can get an array of developers to "weigh in" on the results. As I said, I'm not a "programmer". I was a IT1 9613 commo so I'm more of a hardware guy.
Of course. and ones that still favor Intel ID string. Thats called experimenting.
Otherwise its not the scientific method
ask a question
do research
contruct a hypothesis
do experiments
analyze data
draw conclusion
report results
Drawing a conclusion before your testing is complete is counter productive. In fact, testing and then presenting data and conclusion would be more appropo.
Scientists go all there life trying to prove "they are right" why all their life? With closed source software your screwed. You gotta go open source. That way anyone with the knowledge can look at it too.
Hmm try this same code compiled ion the fast intel compileer and compiled again on a universal compiler. simple math math (for memory) complex math for CPU computations. Serious complex math for CPU calculations. Oh. prime 95. lol If only it was open source and could be setup with different compilers. And had a benchmark associated. that would be the ****.
Its the internet though. I AGREE with you I do. I didnt empirically test it.
and damn if I would want too cuz you are talking a month of free time. Between research and testing. If results are not similar to your hypothesis. And you find one result where there are. thats not empirical thats subjective.
Now do I think that 100 out of 100 tests will come up your way? no I dont I think they are many variables. What you need to do is find quick tests to do that change things, THEN find out why.
test your "standard" benchmarks of course. Not HWbot standard. Standard standard.
You are talking about SSE optimizations but arenot presenting the software as SSE optimized software are you? did you tell us it was? I missed that part.
I am no better, I have ideas all the time. I dont follow through. Dont care I have ideas all the time. Hmm we lost a few weeks ago, my idea is we had a mild winter so branches were not knocked off trees my heavy snow. So now the trees had more surface value and when hit with a 70-100 mph wind, guess hwat more trees fellover. (and more branches that should have fell in winter maybe got knocked off too.. double effect)
I think that is why we lost power for a week. am I right. CANT PROVE IT but I am sure I am right. Im a warm winter fanboy. Oh no thats not right.. Im a cold winter winter fanboy. I am blaming the warm winter on the problems of the community. (Rightly I think) More snow is always better than less snow anyway.
TRopical can kiss my long grass.
Long story short.
Test all your software but stick away from ones that have identification features built in like AIDA64. Im not talking CPU optimizations,. I m saying the primary focus of AIDA64 is a system identification software. It just so happens to have some benchmarks included. You cant do that. And Future ark stuff wont work either. Fop/integer Open3D type stuff benchmarkls
your going to have to go linux. But you cant since people want things they can test. and who uses linux? People that cant even afford bulldozer mostly, still running p3 (nice chip BTW Intel) Or AXP. Better chip BTW...
Second, as for "Bias"...well I guess that's debateable. Maybe "reliability" is a better term, I don't know. IMHO any synthetic benchmark or even "real world" program that ignores the compatibility flags embedded in the CPUID and instead uses the manufacturers name to determine which code to run is unreliable and in some ways "Biased". What does a program care if the name is "AuthenticAMD", "genuineIntel" or "Timbuktu"? The information needed to run ANY type of code is contained within the CPUID. http://developer.amd.com/documentation/articles/pages/4292005119.aspx
To Earthdog, maybe when I'm finished we can get an array of developers to "weigh in" on the results. As I said, I'm not a "programmer". I was a IT1 9613 commo so I'm more of a hardware guy.
Well I am more of an architecture guy and this is what I see.
If each CPU had the same instruction sets with the same exact register layout there is still a big difference. Looking at the L1-L2-L3 sizes (as well as cache timings, hit rate, flush timing... branch prediction and the entire cache architecture), CPU to South Bridge interconnects, CPU to memory BUSes, PCIe lane to CPU architecture, memory controller (and CPU NB) speed... You cant really get into it as far as saying that Intel did or did not do. Guess it is like mounting a Rockchester dual jet to a 351 Clevland.
So you see this is where I base my argument. I do like the testing you are doing however as it should eliminate all of these issue but the funny thing is I think I saw some Intel strings doing badly.
Well I am more of an architecture guy and this is what I see.
If each CPU had the same instruction sets with the same exact register layout there is still a big difference. Looking at the L1-L2-L3 sizes (as well as cache timings, hit rate, flush timing... branch prediction and the entire cache architecture), CPU to South Bridge interconnects, CPU to memory BUSes, PCIe lane to CPU architecture, memory controller (and CPU NB) speed... You cant really get into it as far as saying that Intel did or did not do. Guess it is like mounting a Rockchester dual jet to a 351 Clevland.
So you see this is where I base my argument. I do like the testing you are doing however as it should eliminate all of these issue but the funny thing is I think I saw some Intel strings doing badly.
Kev you are biased cuz you just recently went IvyB. lol im not saying it isn't great I am saying a SandyB at 5 G 24/7 is a good setup. I liked it. At stock I would take a single 7200RPM drive Phenom II x6 with an nice drive and fast ram (CPUNB adjusted accordingly) over a 2500K no OC 1333 mem and any single storage device (minus SATA6 SSD cuz 2xsata2 in raid0 made it feel like an AMD)
heh heh
but im not out to prove anything. I m saying what I like. I prefer AMD cuz of snappiness. Haven't hit 35ns on Intel yet I hope too soon I have come close, they keep pushing bandwidth though, raise the speed limit on the cars capability who care if people die, lol we can throw in extra cabs for ECC.
Well I am more of an architecture guy and this is what I see.
If each CPU had the same instruction sets with the same exact register layout there is still a big difference. Looking at the L1-L2-L3 sizes (as well as cache timings, hit rate, flush timing... branch prediction and the entire cache architecture), CPU to South Bridge interconnects, CPU to memory BUSes, PCIe lane to CPU architecture, memory controller (and CPU NB) speed... You cant really get into it as far as saying that Intel did or did not do. Guess it is like mounting a Rockchester dual jet to a 351 Clevland.
So you see this is where I base my argument. I do like the testing you are doing however as it should eliminate all of these issue but the funny thing is I think I saw some Intel strings doing badly.
That's where you're getting confused. When a program was compiled using the IPP and then run, the CPU dispatcher would then do the "vendor ID check". Where your confusion comes in is that you're assuming at this point that when there's an SSE2 call that BOTH the Intel AND AMD CPU where then allowed to run SSE2 code with the Intel CPU just getting a path that was designed for it and the AMD wasn't. That's not how the instruction sets work. They are standardized. If code is written for SSE2 it will work on all x86/x64 compatible CPU's that have the hardware necessary to run SSE2 built in. Now, one CPU brand might run that code faster than another, but they still both run the code. The CPUID "flags" are the industry standard to tell software which instruction set a particular CPU is capable of running and which ones it can't. If you try to run for example SSE2 code on a CPU that DOESN'T have the SSE2 hardware inside then the CPU will "crash and burn" (i.e. lockup or BSOD on windows). What the Intel compiler did (and possibly still does) was before it checked the compatibility "flags" it would FIRST run the vendor ID check. If it came back as "GenuineIntel" it would then check to make sure that the appropriate instruction set "flag" was present to say "yes I can run that code". If it came back as anything BUT "GenuineIntel" it would STOP and then revert back to the slower x86/x87 code path and it wouldn't even bother to check if the SSE2 etc. "flag" was present and the CPU was even capable of running the code or not. That's not how the Intel compiler started out. It got slipped into a version sometime prior to 2005. Now take that same compiler, disable the vendor ID check and the program compiled will check ALL compatible CPU's to see if the "flag" is there and then run the appropriate code path. And the program will run perfectly fine just as the developer intended. NOW the speed of the program is dependent on which CPU is able to run that code faster.
Edit - What got Intel into trouble is NOT that their compiler does that. It's their compiler and if they want to only run optimized code on their own CPU then they are allowed to. What got them into trouble is that they inserted that code into the compiler AND DIDN'T DISCLOSE THAT TO ANYONE at the same time that they said their compiler optimized and was compatible with all "non-Intel compatible microprocessor". In fact if you read Agner's blog they even denied it at first when he contacted them about it. So now you have a giant corporation that almost gives away it's compiler for free, tells everyone that it's the fastest, best compiler out there that works with all intel compatible CPU's and then secretly inserts code that cripples the speed of the competition's CPU's and then denied it till they got caught red-handed. THAT is what got them into trouble over their compiler and THAT is why they were forced to put that disclosure on their website and THAT is why they were then required to set up a fund to reimburse software developers that had to recompile their software with other compilers to remove that function.
Kev you are biased cuz you just recently went IvyB. im not saying it isn't great I am saying a SandyB at 5 G 24/7 is a good setup. I liked it. At stock I would take a single 7200RPM drive Phenom II x6 with an nice drive and fast ram (CPUNB adjusted accordingly) over a 2500K no OC 1333 mem and any single storage device (minus SATA6 SSD cuz 2xsata2 in riad0 made it feel like an AMD)
heh heh
but im not out to prove anything. I m saying what I like. I prefer AMD cuz of snappiness. Havent hit 35ns on intel yet I hope too soon, they keep pushing bandwidth though, raise the speed limit nto the cars capability who care is people die, ww can throw in extra cabs for ECC.
I'd really rather not have this thread degenerate into an Intel vs AMD "my CPU is bigger than your CPU" thread. This is all about the software not which CPU is better or "faster". And yes I'm going to include ALL results regardless of whether they show differences or not (cinebench being one of those that I've found to not show any difference).
Kev you are biased cuz you just recently went IvyB. im not saying it isn't great I am saying a SandyB at 5 G 24/7 is a good setup. I liked it. At stock I would take a single 7200RPM drive Phenom II x6 with an nice drive and fast ram (CPUNB adjusted accordingly) over a 2500K no OC 1333 mem and any single storage device (minus SATA6 SSD cuz 2xsata2 in riad0 made it feel like an AMD)
heh heh
but im not out to prove anything. I m saying what I like. I prefer AMD cuz of snappiness. Havent hit 35ns on intel yet I hope too soon, they keep pushing bandwidth though
Well I you know why got the IB. It was because I needed to build a new testbed, not because I wanted one. I personally would have preferred a BD but then some manufacturers would have wanted less to do with me. At the moment I am on an old i7 and it is only because I had it laying around and my old PhII could no longer handle the load. Hell currently I am running:
which choked my PhII @ 3.8 GHz \
Everything else is moving to low power AMD or Intel.
By the way I have spent zero personal time on SB or IB other than the SB Celerey in the bedroom HTPC.. Really though I have no preference personally just whatever is laying around that can get the job done.
That's where you're getting confused. When a program was compiled using the IPP and then run, the CPU dispatcher would then do the "vendor ID check". Where your confusion comes in is that you're assuming at this point that when there's an SSE2 call that BOTH the Intel AND AMD CPU where then allowed to run SSE2 code with the Intel CPU just getting a path that was designed for it and the AMD wasn't. That's not how the instruction sets work. They are standardized. If code is written for SSE2 it will work on all x86/x64 compatible CPU's that have the hardware necessary to run SSE2 built in. Now, one CPU brand might run that code faster than another, but they still both run the code. The CPUID "flags" are the industry standard to tell software which instruction set a particular CPU is capable of running and which ones it can't. If you try to run for example SSE2 code on a CPU that DOESN'T have the SSE2 hardware inside then the CPU will "crash and burn" (i.e. lockup or BSOD on windows). What the Intel compiler did (and possibly still does) was before it checked the compatibility "flags" it would FIRST run the vendor ID check. If it came back as "GenuineIntel" it would then check to make sure that the appropriate instruction set "flag" was present to say "yes I can run that code". If it came back as anything BUT "GenuineIntel" it would STOP and then revert back to the slower x86/x87 code path and it wouldn't even bother to check if the SSE2 etc. "flag" was present and the CPU was even capable of running the code or not. That's not how the Intel compiler started out. It got slipped into a version sometime prior to 2005. Now take that same compiler, disable the vendor ID check and the program compiled will check ALL compatible CPU's to see if the "flag" is there and then run the appropriate code path. And the program will run perfectly fine just as the developer intended. NOW the speed of the program is dependent on which CPU is able to run that code faster.
Edit - What got Intel into trouble is NOT that their compiler does that. It's their compiler and if they want to only run optimized code on their own CPU then they are allowed to. What got them into trouble is that they inserted that code into the compiler AND DIDN'T DISCLOSE THAT TO ANYONE at the same time that they said their compiler optimized and was compatible with all "non-Intel compatible microprocessor". In fact if you read Agner's blog they even denied it at first when he contacted them about it. So now you have a giant corporation that almost gives away it's compiler for free, tells everyone that it's the fastest, best compiler out there that works with all intel compatible CPU's and then secretly inserts code that cripples the speed of the competition's CPU's and then denied it till they got caught red-handed. THAT is what got them into trouble over their compiler and THAT is why they were forced to put that disclosure on their website and THAT is why they were then required to set up a fund to reimburse software developers that had to recompile their software with other compilers to remove that function.
Just continue the testing! Honestly I am bias but I am on the side of business not Intel. Perhaps I have been hardened toward all the poor victims out there who want to cry and sue and not stand up and git'er done. This in no way means I support the rampant commercialism I just don't support people who want big brother to fix everything for them.
I'd really rather not have this thread degenerate into an Intel vs AMD "my CPU is bigger than your CPU" thread. This is all about the software not which CPU is better or "faster". And yes I'm going to include ALL results regardless of whether they show differences or not (cinebench being one of those that I've found to not show any difference).
I know WHY you went IB, oh and I think everyone should give you a big round of applause about it. the whole orientation of the heatpipes thing. Wow. I would not have thought of that. Wish I lived closer and we could double review things. that would be AWESOME. If you ever start a review site I hope I am included
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
)
Wow. I would not have thought of that. Wish I lived closer and we could double review things. that would be AWESOME. If you ever start a review site I hope I am included 
