81–90 of 131 posts
Earlier quoted context omitted.
We provided build scripts and source. The extra credit was for fastest execution time. I assume you're payed based on final results, not based on source. Not so crazy of a concept - whoever delivered the best results got rewarded for it.
luckily for you your professor did not have an AMD cpu...
Earlier quoted context omitted.
You were graded based on compiled binaries that you provided, and not based on the source? That sounds crazy to me.
We provided build scripts and source. The extra credit was for fastest execution time. I assume you're payed based on final results, not based on source. Not so crazy of a concept - whoever delivered the best results got rewarded for it.
(2009) Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers: "Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors..." http://software.intel.com/en-us/articles/optimization-notice... http://www.anandtech.com/show/3839/intel-settles-with-the-ft...
> Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers Is it just me or does that not actually fix the problem?
they are not worried about fines. fines are cheap for those companies. they are worried about market control.
they are what they are thanks to phoenix reverse engineering IBM bios and the rise of the generic PC market. Now they fear anyone that can enter the market as easily as they entered and hope to not make the same mistake IBM did.
Earlier quoted context omitted.
What bothers me is that if a mainstream reviewer benchmarks ICC compiled programs, well, that isn't unfair. Real world programs are compiled with that compiler. AMD processors actually WILL under-perform on certain programs because of this. That leaves a bad taste in my mouth.
Maybe any program compiled with ICC should have the same disclaimer as ICC itself so people know that the program is biased.
This all seems to indicate that the intel compiler emits multiple, cpu-dependant code paths for a given binary, which seems insane to me due to the amount of extra memory that this would require. Am I missing something here?
Probably no more insane than loop unrolling, which I understand is fairly standard and well-accepted.
http://www.agner.org/optimize/blog/read.php?i=142 "It is so important to economize the use of the micro-op cache that I would give the advice never to unroll loops."
I don't know how AMD compares.
Earlier quoted context omitted.
Intel is the market leader by a good margin, and in the past has been known to use unfair tactics to keep other players out of the market. AMD has been in a lot of lawsuits with Intel due to this. In this case, it's not just that Intel isn't playing nice with AMD, it's that they're specifically using poor optimizations during compile if you're not using an Intel processor. That's not by accident, that's done on purpo…
Intel is not the market leader in compilers, however: It is somewhat rare to come across teams using the Intel compiler, and they tend to be in niche modeling/simulation or financial realms, more often than not with the sort of code that you compile for a specific piece of deployment hardware, compiling again when you move it to something different. Intel makes the ICC seemingly to try to encourage the adoption of ne…
Earlier quoted context omitted.
> Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers Is it just me or does that not actually fix the problem?
It fixes the legal problem. Intel isn't required to provide an optimized compiler for competitors' chips, but it is required to note that its compiler that is compatible with those chips doesn't optimize code for them. I don't agree either, but it's a perfectly valid solution (and probably the best for Intel's bottom line).
This all seems to indicate that the intel compiler emits multiple, cpu-dependant code paths for a given binary, which seems insane to me due to the amount of extra memory that this would require. Am I missing something here?
Extra code on disk doesn’t cost anything (well disk space, but that is “free” for practical purposes). A compiler can arrange so that all of the code for a given architecture appeared consecutively in the binary, and then the pages and cachelines containing implementations unused by the processor on which you are running are never loaded into memory / never take up space in the cache. Also, in practice code is a tiny…
Earlier quoted context omitted.
You were graded based on compiled binaries that you provided, and not based on the source? That sounds crazy to me.
We provided build scripts and source. The extra credit was for fastest execution time. I assume you're payed based on final results, not based on source. Not so crazy of a concept - whoever delivered the best results got rewarded for it.