text:
Software optimization resources | E-mail subscription to this blog | www.agner.org
|Threaded View
|List Messageboards
|Intel's "cripple AMD" function - Agner Fog - 2009-12-30
|Intel's - Felid - 2010-01-01
|Intel's "cripple AMD" function - inhahe - 2010-01-03
|Intel's - Agner Fog - 2010-01-04
|Intel's compiler is the best? - Weber - 2010-01-04
|Intel's compiler is the best? - Agner Fog - 2010-01-09
|Intel article - Agner Fog - 2010-01-22
|Intel's - Deng - 2016-12-11
|Web Parallels - Jeff Craig - 2010-01-04
|More Parallels - Agner Fog - 2010-01-23
|Early Examples - Yuhong Bao - 2010-02-01
|More Parallels - Yuhong Bao - 2010-02-20
|New CPUID manipulation program - Agner Fog - 2010-01-22
|CPUID manipulation through virtualization - Andrew Lofthouse - 2010-08-16
|CPUID manipulation through virtualization - Agner Fog - 2010-08-16
|CPUID manipulation program for AMD - Agner - 2010-10-01
|CPUID manipulation program for AMD - Ralf - 2012-01-30
|CPUID manipulation program for AMD - Agner - 2012-01-31
|CPUID manipulation through virtualization - akshay - 2015-07-08
|New CPUID manipulation program - AVK - 2011-02-09
|New CPUID manipulation program - Agner - 2011-02-09
|AMD Blog on compilers/benchmarch - margaret lewis - 2010-02-01
|New version is still crippling Intel's competitors - Agner Fog - 2010-06-29
|New version is still crippling Intel's competitors - granyte - 2014-09-16
|Out of court settlement with FTC - Agner Fog - 2010-08-05
|AMD library contains Intel's cripple-AMD function! - Agner Fog - 2010-08-11
|Common math programs are affected - Agner Fog - 2010-08-20
|Preliminary test results for Matlab - Agner Fog - 2010-09-16
|Overview of CPU dispatching in Intel software - Agner Fog - 2010-08-23
|New Intel compiler version - still the same! - Agner Fog - 2010-09-22
|GCC now has support for function dispatch - Jean-Luc - 2010-09-27
|Intel compiler question - James Russell - 2010-10-11
|Intel compiler question - Agner - 2010-10-12
|New Intel compiler version - still the same! - Don Kretsch - 2010-11-29
|New Intel compiler version - still the same! - Daniel - 2011-12-23
|New Intel compiler version - still the same! - Agner - 2011-12-25
|New Intel compiler version - still the same! - Stanley Theamer - 2012-02-12
|New Intel compiler version - still the same! - Stretcho - 2012-03-14
|Still no library that is optimal on all processors - Agner - 2012-04-18
|Still no library that is optimal on all processors - Guest - 2012-05-17
|Still no library that is optimal on all processors - Agner - 2012-05-17
|Still no library that is optimal on all processors - David - 2012-05-19
|Still no library that is optimal on all processors - Agner - 2012-05-20
|Still no library that is optimal on all processors - Bubba_Hotepp - 2012-06-16
|Still no library that is optimal on all processors - Marat Dukhan - 2013-05-20
|Still no library that is optimal on all processors - Agner - 2013-05-21
|This is still going on, wow just wow - Vuurdraak - 2016-11-10
|This is still going on, wow just wow - Agner - 2016-11-10
|This is still going on, wow just wow - Vuurdraak - 2016-11-11
|This is still going on, wow just wow - Denis - 2017-01-02
|This is still going on, wow just wow - Agner - 2017-01-02
|Intel's "cripple AMD" function
|Author: Agner Fog
|Date: 2009-12-30 10:22
Will Intel be forced to remove the "cripple AMD" function from their compiler?
Many software programmers consider Intel's compiler the best optimizing compiler on the market, and it is often the preferred compiler for the most critical applications. Likewise, Intel is supplying a lot of highly optimized function libraries for many different technical and scientific applications. In many cases, there are no good alternatives to Intel's function libraries.
Unfortunately, software compiled with the Intel compiler or the Intel function libraries has inferior performance on AMD and VIA processors. The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.
I have complained about this behavior for years, and so have many others, but Intel have refused to change their CPU dispatcher. If Intel had advertised their compiler as compatible with Intel processors only, then there would probably be no complaints. The problem is that they are trying to hide what they are doing. Many software developers think that the compiler is compatible with AMD processors, and in fact it is, but unbeknownst to the programmer it puts in a biased CPU dispatcher that chooses an inferior code path whenever it is running on a non-Intel processor. If programmers knew this fact they would probably use another compiler. Who wants to sell a piece of software that doesn't work well on AMD processors?
Because of their size, Intel can afford to put more money into their compiler than other CPU vendors can. The Intel compiler is relatively cheap, it has superior performance, and the support is excellent. Selling such a compiler is certainly not a profitable business in itself, but it is obviously intended as a way of supporting Intel's microprocessors. There would be no point in adding new advanced instructions to the microprocessors if there were no tools to use these instructions. AMD is also making a compiler, but the current version supports only Linux, not Windows.
Various people have raised suspicion that the biased CPU dispatching has made its way into common benchmark programs (link link). This is a serious issue indeed. We know that many customers base their buying decision on published benchmark results, and a biased benchmark means an unfair market advantage worth billions of dollars.
The legal battle
AMD have sued Intel for unfair competition at least since 2005, and the case has been settled in November 2009. This settlement deals with many issues of unfair competition, apparently including the Intel compiler. The settlement says:
This looks like a victory for AMD. If we read "any Intel product" as Intel's compilers and function libraries, "any Third Party" as programmers using these compilers and libraries, and "Artificial Performance Impairment" as the CPU dispatcher checking the vendor ID string; then the settlement puts an obligation on Intel to change their CPU dispatcher. I will certainly check the next version of Intel's compiler and libraries to see if they have done so or they have found a loophole in the settlement.
Interestingly, this is not the end of the story. Only about one month after the AMD/Intel settlement, the US Federal Trade Commission (FTC) filed an antitrust complaint against Intel. The accusations in the FTC complaint are unusually strong:
The remedy that the FTC asks for is also quite farreaching:
Maybe the FTC has decided that the AMD/Intel settlement was not a fair and sufficient remedy against Intel's monopoly behavior? The settlement compensates AMD, but not VIA and other microprocessor vendors, and not the customers who have been harmed by insufficient competition and by the "defective" software produced with the Intel compiler.
My own findings
When I started testing Intel's compiler several years ago, I soon found out that it had a biased CPU dispatcher. Back in January 2007 I complained to Intel about the unfair CPU dispatcher. I had a long correspondence with Intel engineers about the issue, where they kept denying the problem and I kept providing more evidence. They said that:
Sounds nice, but the truth is that the CPU dispatcher didn't support SSE or SSE2 or any higher SSE in AMD processors and still doesn't today (Intel compiler version 11.1.054). I have later found out that others have made similar complaints to Intel and got similarly useless answers (link link).
The Intel CPU dispatcher does not only check the vendor ID string and the instruction sets supported. It also checks for specific processor models. In fact, it will fail to recognize future Intel processors with a family number different from 6. When I mentioned this to the Intel engineers they replied:
In other words, they claim that they are optimizing for specific processor models rather than for specific instruction sets. If true, this gives Intel an argument for not supporting AMD processors properly. But it also means that all software developers who use an Intel compiler have to recompile their code and distribute new versions to their customers every time a new Intel processor appears on the market. Now, this was three years ago. What happens if I try to run a program compiled with an old version of Intel's compiler on the newest Intel processors? You guessed it: It still runs the optimal code path. But the reason is more difficult to guess: Intel have manipulated the CPUID family numbers on new processors in such a way that they appear as known models to older Intel software. I have described the technical details elsewhere.
Perhaps the initial design of Intel's CPU dispatcher was indeed intended to optimize for known processor models only, without regard for future models. If any of my students had made such a solution that was not future-oriented, I would consider it a serious flaw. Perhaps the Intel engineers discovered the missing support for future processors too late so that they had to design the next generation of their processors in such a way that they appeared as known models to existing Intel software.
After Intel had flatly denied to change their CPU dispatcher, I decided that the most efficient way to make them change their minds was to create publicity about the problem. I contacted several IT magazines, but nobody wanted to write about it. Sad, but not very surprising, considering that they all depend on advertising money from Intel. The only publicity was my own optimization manual where I have described the problem in detail and given instructions on how to replace the unfair CPU dispatcher. I wonder why AMD didn't create public awareness about the problem. Were they obliged to keep quiet about an ungoing lawsuit? And what about VIA/Centaur?
At present, we don't know if or when Intel will make a new compiler and new software libraries that do not check the vendor ID string. In the meantime, here is what we can do about the problem.
My Discussion in Aceshardware forum 2007.
Discussion in AMD Developer Forums 2008.
My Discussion in AMDzone 2009.
Complaint to Intel 2004, discussion in slashdot.org.
Mark Mackey, complaint to Intel 2005.
PCMark 2005 benchmark proven unfair. Arstechnica.
Testimony by John Oram regarding BAPCo benchmark organization.
Comment on AMD Developer Central 2005.
AMD untitrust complaints 2005.
Settlement agreement between AMD and Intel, 2009.
Technical details in my C++ optimization manual.
[Added later:]
Discussion on XtremeSystems Forum.
|Reply To This Message
|Date: 2010-01-01 12:50
"It is possible to change the CPUID of AMD processors by using the AMD virtualization instructions. I hope that somebody will volunteer to make a program for this purpose."
How exactly we can do that? As of now the simpliest option is to change vendor strings embedded in executables to compare with CPU's. We're at iXBT.com are doing this right now and will publish test results soon (Intel & AMD CPU's, Intel <-> AMD & AMD <-> Intel string change, 4-6 runs per app, 50-100 app's). If it is OK to use your findings (with all the copyrights), we will :)
|Reply To This Message
|Intel's "cripple AMD" function
|Date: 2010-01-03 18:37
|I think it's arguable whether or not Intel crippled AMD via an "affirmative engineering or design action" as opposed to a "failure to act" (as distinguished in the settlement). They optimize code paths based on Vendor ID, which obviously has to do with more than supported instruction sets, or they wouldn't have to do it by processor family, etc. I doubt Intel can be required to optimize specifically for a CPU that's not theirs (also implying they wouldn't necessarily know its internal workings in order to do so).
Yes, it may be true that the same code paths they used for Intel CPUs would have optimized well for AMD CPUs, but Intel probably isn't required to know that. Also, their code path optimizations are apparently targeted for specific vendors (namely, theirs, I guess) and models, not generic strategies, so it would have been a hack for them to apply an Intel-derived code path to AMD processors, because, while being better than no optimizer, the code might also include superfluous and deleterious algorithms as applied to AMD CPUs. Yes, it's pragmatic to do so and would have been better for consumers, but can we ethically require them to engineer a dirty hack into their programming structure? Another reason it's a gray area is that it's possible that the code path optimizations they took were obvious and would likely apply to any modern x86 CPU (though the fact that AMD and Intel are the only two players in the game sort of makes it beg the question), and if only some of them were obvious those optimizations may or may not be modularized already for easy extraction and universal use.
From a business standpoint, this was obviously a strategic decision on Intel's part to undermine AMD, but if it's an ideological grey area whether they undermined AMD or simply took advantage of the fact that they happen to be the producers of one of the CPUs they compile for in order to improve their compiler for their *own* product, then they can't necessarily be faulted, because the law requires evidence and analysis. (Taking in-house advantage isn't necessarily anti-competitive in itself; for example, Microsoft makes plenty of applications that run on their own OS but not on Linux or Mac OS.)
It is true that the settlement they issued flat-out admits wrongdoing; i.e., it implies that they did, in fact, effect an "affirmative or design action" meant to undermine AMD. As far as I can see there are three possible reasons for this.
Of course it complicates the matter that there is actually a complete instruction set (SSE) that they don't support for the AMD. They have an excuse for that. Whether or not it's valid who knows. Since they do support that instruction set, it would seem deliberate "affirmative action" to disable it on AMD since AMD supports it in exactly the same way that Intel does on a purely functional level (independently of speed), and SSE is generally more efficient when applicable. However, if the decisions for how and when to use SSE instructions are intricately tied in with the rest of their code path algorithm (and possibly rely on internal structure of the CPU design), then the caveats I brought up earlier still apply.
In any case, whether not supporting optimizations on AMD's CPUs was an affirmative design decision to undermine AMD machines or merely a failure to act (to benefit AMD machines), either way, it's clearly wrong for them to publish benchmarks to OEMs, etc. comparing AMD CPUs to Intel CPUs using their own compiler that specifically optimizes for Intel CPUs (based on Vendor ID no less!, but either way) and not for AMD CPUs. It's misleading, and according to the UTC, even when specifically confronted with the issue they would habitually either mislead or directly lie about the cause for the speed difference and whether it could be solved. So *that's* the part that's really devious, and I can see why the FTC sued them. I *hate* companies like that. Incidentally, though, all companies are companies like that.
|Reply To This Message
|Author: Agner Fog
|Date: 2010-01-04 03:28
|inhahe wrote:
I think it's arguable whether or not Intel crippled AMD via an "affirmative engineering or design action" as opposed to a "failure to act" (as distinguished in the settlement).Checking for vendor ID is an affirmative action. The grey area is whether they are optimizing for specific CPU models or for specific instruction sets. There is only one case where they distinguish between different CPU models that have the same instruction set, namely Pentium 4 versus Pentium M. In most cases, however, they use the same code path for both, or the two paths are identical or almost identical. The distinction may be unimportant from a technical point of view, but it may give Intel a legal excuse for claiming that they are optimizing for specific CPU models.
I doubt Intel can be required to optimize specifically for a CPU that's not theirsThe settlement doesn't require that.
Another reason it's a gray area is that it's possible that the code path optimizations they took were obvious and would likely apply to any modern x86 CPU (though the fact that AMD and Intel are the only two players in the game sort of makes it beg the question),Most optimizations are indeed obvious applications of the available instruction set. If you have SSE2 you can do four additions in one instruction. That's an obvious thing to do regardless of CPU model. Don't forget there is a third player, VIA. Their chips are fast enough for being relevant here.
given the small excerpt of the settlement shown, it seems possible to me that what they *actually* did is make something up that will sate AMD's lawyers while at the same time leaving the door open for them to either continue the same practice, or cease the practice (if it's too obviously anti-competitive or if they explicitly said they'd cease it elsewhere) but instate similar and/or related practices in the future, on account of the fact that those practices can easily be classified as "failures to act." [...] However, if the decisions for how and when to use SSE instructions are intricately tied in with the rest of their code path algorithm (and possibly rely on internal structure of the CPU design), then the caveats I brought up earlier still apply.Yes, they will probably be able to claim that. From a merely technical perspective, I think it's a bad idea to make different code paths for two processors that support the same instruction set based on whether a particular instruction runs a little faster on one than on the other. If you consider the time it takes to develop a complete program plus the time it takes to market it, then it is likely that the processors you optimized for will be obsolete for your most demanding customers before the time your software peaks on the market. My advise would certainly be to optimize for the newest processor, but make sure you maintain compatibility with older processors.
But of course Intel compiler engineers are not obliged to listen to my advice if doing otherwise enables them to harm their competitors.
In any case, whether not supporting optimizations on AMD's CPUs was an affirmative design decision to undermine AMD machines or merely a failure to act (to benefit AMD machines), either way, it's clearly wrong for them to publish benchmarks to OEMs, etc. comparing AMD CPUs to Intel CPUs using their own compiler that specifically optimizes for Intel CPUs (based on Vendor ID no less!, but either way) and not for AMD CPUs. It's misleading, and according to the UTC, even when specifically confronted with the issue they would habitually either mislead or directly lie about the cause for the speed difference and whether it could be solved. So *that's* the part that's really devious, and I can see why the FTC sued them. I *hate* companies like that. Incidentally, though, all companies are companies like that.Fortunately, not all companies are like that. I am sure this case has harmed Intel's reputation. They can be damn sure that their next compiler version will be thoroughly scrutinized. Hopefully, they will take their reputation into account when they design the next compiler version and function libraries.
|Reply To This Message
|Intel's compiler is the best?
|Author: Weber
|Date: 2010-01-04 16:46
|You wrote: "There is no other Windows compiler with a similar performance, not even the Gnu compiler for Windows."
Which compilers did you test?
Did you try e.g. the Portland Group (PGI) compiler? That means, does Intel's compiler (icc) produce faster executables than e.g. the PGI compiler for Intel CPU's? Does icc (with a patched CPU dispatcher) even produce faster executables than e.g. PGI for AMD CPU's?
Not that I'd try to challenge your claims (I haven't benchmarked any of the compilers), I'm just interested. Thanks! :-)
|Reply To This Message
|Intel's compiler is the best?
|Author: Agner Fog
|Date: 2010-01-09 04:23
|Weber wrote:
Which compilers did you test?You can see my comparison of compilers in my C++ manual. The PathScale and PGI compilers are also fairly good, but not the best.
|Reply To This Message
|Intel article
|Author: Agner Fog
|Date: 2010-01-22 04:04
|Intel have just published an article on how the CPU dispatching works in the Intel Performance Primitives (IPP) function library, see software.intel.com/en-us/articles/intel-integrated-performance-primitives-intel-ipp-understanding-cpu-optimized-code-used-in-intel-ipp/
The article indicates a fair handling of non-Intel processors in the IPP library. This is in accordance with my test results.
What the article doesn't mention is the unfair CPU dispatching in several other Intel function libraries :-)
|Reply To This Message
|Author: Deng
|Date: 2016-12-11 20:43
|Recently I tested the inteldispatchpatch.zip (2014-07-30) in asmlib on MKL library in Intel Parallel Studio 2015 Update 3.
It gave me error like "Intel MKL ERROR: CPU 1 is not supported." on AMD servers. (from mkl_blas_xdgemv ()). If removing the 'dispatchpatch64.o' during linking, the MKL works on AMD servers.
It seems to me that the dispatch does not work on newer Intel MKL. do you know more way how to patch it correct?
inhahe wrote:
|Reply To This Message
|Web Parallels
|Date: 2010-01-04 10:12
|Really fascinating article. I've generally deferred to open source compilers, like GCC, but that's largely been because of preferring open source to proprietary software when possible. I'd not realized that Intel was doing this in their compilers, which is a major concern for me, since I purchased an Intel desktop processor for home use in well over a decade.
What I found most interesting, is how this seems to parallel a fight we've been having in the web development community a lot over the last five years or so, on the benefits of feature detection versus browser detection. I'll defer to Nicholas Zakas' explanation here: www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/
Now, on the web it's a bit trickier, web browsers' behaviour tends to be considerably more variable than x86 behaviour across different vendors, but ultimately, the desire is the same. Check what is supported, and select code-paths based on what's supported, not based on whether you're on IE or Safari or Firefox, etc. And the bad design is generally made by the developer, not some third-party vendor (though not always, as Nicholas talks about in his post).
I'm going to be publicizing this issue, to the best of my ability, since I think it's important that people understand the implications of choosing to use Intel's compiler, which is otherwise quite high quality. And, while I didn't understand why the antitrust suit was filed by the US government when it was announced, I'm certainly far more interested in it's outcome than I was before.
|Reply To This Message
|More Parallels
|Author: Agner Fog
|Date: 2010-01-23 02:28
|I have always thought that it is bad programming practice to make software that relies on specific CPU brands and models. Any program that makes assumptions based on the CPU model number is likely to be obsolete as soon as a new processor appears on the market.
Unfortunately, this practice is more widespread than I thought. Here are some examples:
|Reply To This Message
|Early Examples
|Date: 2010-02-01 22:03
|In fact, it dates to when AMD released the Athlon XP back in 2001, which was I think the first non-Intel processor that supported SSE. Back then it was discovered that Windows Movie Maker 1.1 shipped with the original RTM release of Windows XP as well as Windows Movie Encoder 7 did not use SSE on non-Intel processors. Luckily by the time of the XP launch in October 2001, MS was ready with WMM 1.2, as well as WME 7.1, which removed the vendor check, and AMD itself had patches as well. BTW, It was reported that it accounted for a dip in the Sysmark 2001 and Winstone 2002 Content Creation benchmarks.
|Reply To This Message
|More Parallels
|Date: 2010-02-20 23:56
|Also, currently OpenSolaris checks for a vendor of GenuineIntel before using SSSE3 and later extensions. While that wasn't a problem initially when the code was written because only Intel implemented them and AMD was going to go their own path with SSE5, VIA now implement them too with the Nano, and AMD later decided to change and implement all of them up to AVX in Bulldozer.
Bug has been filed at:
|Reply To This Message
|New CPUID manipulation program
|Author: Agner Fog
|Date: 2010-01-22 03:54
|It it possible to manipulate the CPUID in VIA Nano processors. This feature is currently undocumented, and it is different from the method described in manuals for earlier VIA processors. I have got the necessary information now, and I have made a little program that can change the CPUID vendor string, family and model number on a VIA Nano processor.
You can download the program from www.agner.org/optimize/cpuidfake.zip. It is open source (GPL). Please read the included instructions.
The program requires a VIA Nano processor, and Windows (32 or 64 bit). This program makes it possible to test if a benchmark result depends on the CPUID vendor string. You can also test if the performance of other CPU-intensive programs perform differently depending on the CPUID.
If you find any benchmark or other generally used CPU-intensive program that appears to have an unfair CPU dispatching then please let me know. You may also contact the producer of the program and ask if it has been built with an Intel compiler or Intel function libraries. It is important to know how widespread this problem is.
|Reply To This Message
|CPUID manipulation through virtualization
|Date: 2010-08-16 08:31
|If you do not have a VIA processor, you can also test applications using a VMWare virtual machine. If VMWare is using hardware virtualization, all cpuid instructions are intercepted and hence can be spoofed. Using the following lines in my .vmx file, I can change the vendor_id string from GenuineIntel (I have a Core 2 Duo) to AuthenticAMD:
I've verified the behavior of Intel's Compiler using this method...
|Reply To This Message
|CPUID manipulation through virtualization
|Author: Agner Fog
|Date: 2010-08-16 12:24
|Andrew Lofthouse wrote:
If VMWare is using hardware virtualization, all cpuid instructions are intercepted and hence can be spoofed.Thanks a lot for the tip. Now everybody can test if their software has vendor-specific performance. You can get a 60 days evaluation from VMWare or get the server version for free.
By analogy to Andrew's code, I assume that you can make an AMD processor spoof to be "GenuineIntel" with these lines:
cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111" cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001" cpuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"The Intel software also checks the family number, which should be set to 6:
cpuid.1.eax="0000:0000:0000:0001:0000:0110:0111:0001"You can verify this with CPUID.
Anybody who finds software with a strong performance effect of the vendor string are welcome to post the details here or mail them to me.
I am currently testing this effect in various math programs. I will post the findings here soon.
|Reply To This Message
|CPUID manipulation program for AMD
|Author: Agner
|Date: 2010-10-01 06:11
|Here is a CPUID manipulation program for AMD processors that I have received from a Russian friend. link. I haven't tested it. Use it at your own risk. Explanation.
|Reply To This Message
|CPUID manipulation program for AMD
|Date: 2012-01-30 19:15
|I just came across this:
Not what I want though, I'm googling for a way to make KVM return "GenuineIntel" for the CPUID instruction.
|Reply To This Message
|CPUID manipulation program for AMD
|Author: Agner
|Date: 2012-01-31 01:56
|Ralf wrote:
I just came across this: https://github.com/jimenezrick/patch-AuthenticAMDThanks for the reference. The patch program is not a perfect solution. I would prefer that the patch skips the vendor string test rather than replace it with a test for "AuthenticAMD" so that it would work with any vendor. It should also remove the check for CPU family number. But it's a quick solution in some cases, including Intel .DLL and .SO library files. Try it at your own risk, and make sure you make a backup first :)
|Reply To This Message
|CPUID manipulation through virtualization
|Date: 2015-07-08 04:13
I have been trying to install mac os 10.8.2 using souldev teams tutorial, in vmware.
cpu- amd athlon
tried with several versions of vmware (8,9 series) and same error every where
Thanks advance.
|Reply To This Message
|New CPUID manipulation program
|Author: AVK
|Date: 2011-02-09 00:55
|Mr. Fog,
Have you read AMD #43170 document "BKDG for AMD Processors Family 14h?" In there, on page 319, I've noticed an interesting table 102 named as: "Reset mapping for CPUID Fn0000_0000_E[B,C,D]X". What do you think about the "Reset mapping" sentence? Does it mean that AMD CPUs finally get a feature to change its CPUID.Vendor string like VIA CPUs have? If it so, would you update your CPUID Fake utility?
|Reply To This Message
|New CPUID manipulation program
|Author: Agner
|Date: 2011-02-09 02:15
|AVK wrote:
Does it mean that AMD CPUs finally get a feature to change its CPUID.Vendor string like VIA CPUs have?Unfortunately not. It is read-only.
|Reply To This Message
|AMD Blog on compilers/benchmarch
|Date: 2010-02-01 18:50
|Posted a blog on compilers/benchmarks - Chipping Away the Fa�ade on Compilers and Benchmarks for AMD Processors
|Reply To This Message
|New version is still crippling Intel's competitors
|Author: Agner Fog
|Date: 2010-06-29 04:16
|Intel have released a new version of their Math Kernel Library (v. 10.3) in beta test.
I have tested the new libraries and found that the CPU dispatching works basically the same way as before. The standard math library, vector math library, short vector math library and the 64-bit version of other math kernel library functions still use an inferior code path for non-Intel processors.
I have found the following differences from previous versions:
Obviously, I haven't tested all functions in the library. There may be more differences that I haven't discovered. But it is clear that many functions in the new version of the library still cripples performance on non-Intel processors. I don't understand how they can do this without violating the legal settlement with AMD.
|Reply To This Message
|New version is still crippling Intel's competitors
|Date: 2014-09-16 04:37
|I recently peeked at the generated code for the intel c++ compiler suite 2015 when on x64 not only is the cpu dispatcher present but it seem there is an entry for AuthenticAMD in it I sadly don't have enough knowledge about x64 assembly to know what is going on
|Reply To This Message
|Out of court settlement with FTC
|Author: Agner Fog
|Date: 2010-08-05 09:43
Out of court settlement with FTCYesterday, the Federal Trade Commission (FTC) announced that they are going for an out of court settlement with Intel. See their press release and proposed decision.
I will comment only on the part of the settlement that deals with Intel's compilers and function libraries. The FTC orders that Intel must inform its software customers about the CPU dispatch mechanism that leads to suboptimal performance on non-Intel CPUs. It also recognizes that certain published benchmarks were misleading. The advantage of an out-of-court settlement is that it is faster. A court battle could take so long time that the issues were obsolete before a decision was made. In a comment, the FTC explains that the purpose of the order is not punitive but remedial.
The settlement with FTC is less far-reaching than the settlement with AMD. The AMD settlement requires that Intel remove any "Artificial Performance Impairment", while the FTC settlement requires only that Intel inform their customers of what they do. This will not solve the problem, only make it more visible. The wording of the settlement is also somewhat ambiguous as to which clauses apply to both the compiler and the function libraries, and which clauses apply to the compiler only. This is unfortunate since many software developers are using the Intel function libraries without using the Intel compiler.
The FTC have asked me to testify in court about the CPU dispatching in Intel's compilers and function libraries. I will not have to do this now, of course, but I will continue to publish my findings here on my blog. I am currently doing a survey of software that is affected by the biased CPU dispatching and I am going to publish the results here soon.
Since Intel have not removed the biased CPU dispatching from their MKL library despite the settlement with AMD, and since the settlement with FTC does not require them to do so, we can expect that the problem will persist.
It is interesting that the FTC in their comment suggests that software developers can override the code dispatch mechanisms in Intel compilers and libraries. This is a technique that I have developed and described in my C++ manual. However, I doubt that commercial software developers will be happy to use such hacking techniques that rely on undocumented features.
The response of the software community will probably be to avoid Intel software products entirely. In my test of the optimizing performance of C++ compilers, the Intel compiler and the Gnu compiler for Linux shared the first place. Unfortunately, the Gnu compiler for Windows is not up to date so we still need a good replacement for the Intel compiler for Windows. It is not a profitable business to make a well optimized math function library. If we cannot use Intel's libraries then we probably have to rely on the open source community for making such libraries. The Gnu function libraries (glibc) are not very well optimized, so there is still a lot of work to do. The work of optimizing the Gnu function libraries is going very slowly and is done mainly by an Intel guy. Why don't AMD and independent programmers contribute to this work to make sure the software performs well on non-Intel processors as well?
After all, the FTC settlement leaves the software community with more problems than we could expect after the AMD settlement. Maybe this reflects the limited power of the FTC?
|Reply To This Message
|AMD library contains Intel's cripple-AMD function!
|Author: Agner Fog
|Date: 2010-08-11 10:57
This issue is getting more and more absurd the more I dig into it. AMD makes a function library called AMD Core Math Library (ACML) to match Intel's Math Kernel Library (MKL). I have tested a Windows version of ACML and found that some of the functions run faster when the CPU vendor ID is artificially changed to "GenuineIntel". Maybe this is not so surprising after all, since this version of ACML is compiled with Intel's Fortran compiler.
Here are some of the most marked test results:
On many of the functions in ACML there is little or no difference in performance depending on the CPU vendor ID, but some functions have a significant bias, as shown in the table above. Intel have repeatedly claimed that their compilers give a good performance on AMD chips if you compile for the SSE2 instruction set. Maybe the AMD people have believed this claim, or maybe they had no other option since they couldn't find a better Fortran compiler. With this compiler option, the compiler-generated code will be for the SSE2 instruction set only. I think that Intel first made the SSE2 recommendation at the time when AMD processors supported only SSE2, so this was the best performance you could get at that time. Today, you get suboptimal performance when compiling for SSE2 because later instruction sets are not used. And of course, the code will not work on older computers without SSE2.
To find the reason for the vendor ID effect, I decided to investigate the function with the strongest effect, which is the drandlognormal function. After a lot of detective work, I found that drandlognormal calls a logarithm function in Intel's Short Vector Math Library (SVML). This logarithm function is dispatched into three branches for the SSE2/generic, SSE3, and the future AVX instruction set, respectively. It uses the standard Intel CPU dispatcher, which gives the generic branch to all non-Intel processors. The SVML library supports only SSE2 and above, so the generic branch uses SSE2. When my VIA processor fakes to be an Intel, it gets the SSE3 branch, which is better optimized. The difference in performance is likely to be higher on future processors that support AVX.
There is another version of ACML for Windows built with the PGI compiler, but I couldn't make it work because some library files were missing.
The proposed settlement with FTC requires that Intel shall reimburse its compiler customers for the cost of recompiling their code with a different compiler. While this reimbursement program probably has little more than symbolic significance, it would be funny to see Intel compensating AMD for relying on their compiler. Unfortunately, it will be difficult for AMD to find a better Fortran compiler.
|Reply To This Message
|Common math programs are affected
|Author: Agner Fog
|Date: 2010-08-20 11:05
Back in January, I made a tool to manipulate the CPUID of VIA processors and published the code here in the hope that somebody would test a lot of programs to see if the performance depends on the CPU vendor. The research staff of a Russian IT webzine iXBT.com offered to help with this. I gave them some equipment that they couldn't get in Russia, and they have tested a lot of programs. Their results are published in Russian, and later also in English.
The Russian researchers found several programs where the performance depended on the vendor name on the CPU. While this is ground for suspicion, it does not necessarily mean that Intel software is involved. It is necessary to make a deeper investigation in order to see if the programs are compiled with an Intel compiler or an Intel function library.
I noticed from the screening results that Matlab and Mathematica were among the programs where the vendor name effect was highest. I decided therefore to make further investigations of mathematical programs and found that Mathcad was also affected. Matlab, Mathematica and Mathcad are the most commonly used math programs at universities and colleges.
Below are the results of my investigations so far on a VIA Nano L3050, 1.8 GHz.
Mathematica version 7.0.1 was tested using the BenchmarkReport function that is included with the package. The overall benchmark result for different (faked) CPU vendors was as follows (average of 5 tests):
A further investigation shows that Mathematica uses the Intel Math Kernel Library (MKL version 10.1 beta, 2008),
including the Vector Math Library (VML) which contains optimized code paths used exclusively for Intel processors, and the Gnu Multiple Precision Arithmetic Library (GMP,
no version info), which contains Intel-specific and AMD-specific code paths but no VIA-specific code paths. Another executable file (mathdll.dll) with Mathematica's own kernel code contains a check for the Intel vendor string, but I could not find out what the purpose of this check is, and I found no evidence that it originates from Intel software.
Mathcad version 15.0 was tested with some simple benchmarks made by myself. Matrix algebra was among the types of calculations that were highly affected by the CPU ID. The calculation time for a series of matrix inversions was as follows:
Using a debugger, I could verify that it uses an old version of Intel MKL (version 7.2.0, 2004), and that it loads different versions of the MKL depending on the CPU ID as indicated in the table above. The speed is more than doubled when the CPU fakes to be an Intel Pentium 4.
It is interesting that this version of MKL doesn't choose the optimal code path for an Intel Core 2. This proves my point that dispatching by CPU model number rather than by instruction set is not sure to be optimal on future processors, and that it sometimes takes years before a new library makes it to the end product. Any processor-specific optimization is likely to be obsolete at that time. In this case the library is six years behind the software it is used in.
I haven't got a Matlab package for testing yet, so the detailed results will have to wait. However, it is known that Matlab uses Intel's MKL library. The Russians report that Matlab runs 28% slower when the CPU identifies as a VIA compared to an Intel Core 2.
Apparently, the Matlab people are aware of the problem because they have announced that they are now using Intel's MKL library on Intel machines, and AMD's ACML library on AMD machines for basic linear algebra calculations. However, this is probably no improvement. Our Russian friends reported two years ago that Matlab runs faster with MKL than with ACML on an AMD machine!
It may sound like a fair solution that each CPU vendor makes its own function libraries, but this can soon be a nightmare for the producers of application software. This goes against the very principle of having a standardized instruction set. And apparently, only Intel can afford the costs of optimizing large function libraries on the detailed instruction level. They don't make much money on these function libraries, and it is surely very costly to develop, test and optimize such a big library of complicated mathematical functions, let alone the costs of making a different version for every new instruction set extension. The AMD libraries cannot match this level of optimization, and VIA can hardly afford to make any function libraries at all.
This is the core of the problem. By investing in the development of large, comprehensive and highly optimized math libraries, Intel have obtained a dominating market position in mathematical software, but in a very subtle way. They are not making the application software for the end user; but they are making some of the tools and building blocks for making such software. This enables them to manipulate the performance of this software on the CPUs produced by their competitors. And this manipulation is completely invisible to the end user and perhaps even to the application programmer. In fact, Intel have managed to put their CPU dispatcher into an AMD function library, as revealed in a previous post here.
Intel are putting themselves into an advantageous position by making better function libraries than everybody else, and they are taking advantage of this position by lowering the performance of common mathematical software on the CPUs of their competitors relative to their own. We have probably not seen the end of the legal battles yet.
|Reply To This Message
|Preliminary test results for Matlab
|Author: Agner Fog
|Date: 2010-09-16 07:20
Preliminary test results for Matlab
I have now verified that the performance of Matlab depends strongly on the CPU vendor string. The benchmark test on my VIA processor gives the following results.
These differences in benchmarks are mostly due to the fact that Matlab uses different function libraries for different processors. (The graphics performance is irrelevant here since I have no proper graphics card on my test board).
It is possible to choose different function libraries by modifying two poorly documented configuration files, named blas.spec and fftw.spec.
By modifying these configuration files, I got the following benchmarks for different function libraries on the VIA processor.
This shows that most of the difference in performance can be accounted for by the fact that Matlab has specified different libraries to be used on different processor brands. The Matlab configuration files make specifications only for Intel and AMD processors, while VIA processors get a default library. Apparently, they have never heard about VIA processors. As you can see, the speed can be more than doubled for some tasks by adding an appropriate specification for VIA processors to the configuration files.
Next, I analyzed the library files to see if there was any CPU dispatching inside these libraries. This analysis gave the following results:
default blas library
FFT libraries
My conclusion so far is that the performance of Matlab depends strongly on the CPU vendor string, but this effect is mainly due to suboptimal settings in the configuration files, and this problem can be solved easily by modifying these files. Several of the library files contain Intel CPU dispatchers that favorize Intel processors, but the effect of this is too small to give statistically significant results in my tests.
So far, I have only made tests on a single-core processor. There may be larger effects on multi-core processors, but I have not been able to test this yet. I have made a small test package with the appropriate configuration files and descriptions for my readers to experiment with. You can download it here.
|Reply To This Message
|Overview of CPU dispatching in Intel software
|Author: Agner Fog
|Date: 2010-08-23 06:38
There are many different versions of Intel compilers and function libraries with different CPU dispatching schemes. Some of these are fair to non-Intel processors and some are unfair. By unfair dispatching I mean that it chooses a suboptimal code path when running on a non-Intel CPU even when the CPU is compatible with a better code path. The different versions can get quite confusing, so I have tried to test as many different versions of Intel software products as I could get my hands on and present an overview of the results here.
The tables below show the highest instruction set available to Intel and non-Intel processors when running the different software products. The sequence of instruction sets have the not very logical names:
Intel Math Kernel Library
The Math Kernel Library (MKL) contains many advanced mathematical functions. The results in the following table do not apply to various (sub-)packages that may be bundled with the MKL, such as the Intel Vector Math Library (VML), Intel Performance Primitives (IPP) and Intel Threading Building Blocks (TBB).
As we can see, version 8 and 9 give Intel and non-Intel processors access to the same instruction sets, while version 7 and the 64-bit version 10 have unfair dispatching. MKL 7.0 has no x86-64 version.
Intel Vector Math Library
The Vector Math Library (VML) contains procedures for calculating elementary mathematical functions on vectors of arbitrary size.
As we can see, all versions have unfair dispatching. There are different branches for Intel processors with SSE2 and non-Intel processors with SSE2. I have not tested which of the SSE2 branches run fastest on non-Intel processors.
Intel Performance Primitives
All the versions I have tested have fair CPU dispatching.
Intel Threading Building Blocks
This library has some CPU dispatching, but I have not tested whether it is fair or not.
Intel standard C library and standard math library
These libraries are called automatically from code compiled with an Intel C++ compiler.
All versions have unfair CPU dispatching. In many cases, however, the Intel compiler can generate calls directly to the SSE2 version of a function when compiling for the SSE2 or higher instruction set. This also applies to non-Intel processors.
Intel Short Vector Math Library
The Short Vector Math Library (SVML) is used for elementary mathematical functions on vector registers (XMM and YMM registers). It is called automatically from code compiled with an Intel compiler when the SSE2 or higher instruction set is enabled. The SVML can also be used with other compilers such as the Gnu C++ compiler.
Intel C++ compiler
The Intel C++ compiler has various options that allow the programmer to generate code for a specific instruction set or to make multiple versions of the code for different instruction sets with automatic CPU dispatching. Non-Intel processors will always get the generic version of the code if CPU dispatching is used. The default level for the generic code is SSE2 for version 11 and 12 of the compiler, and 386 for version 10 and earlier in 32-bit mode as indicated in the following table.
There is an option
for setting the generic level higher or lower. For example, the options
Other Intel products
The above test results are obtained with Intel C++ compilers and function libraries for Windows and Linux. I have found no differences between the Windows and Linux versions in the cases where I have had access to both. I have not tested the Macintosh versions, but this is less relevant as long as no Macintosh computers are available with AMD or VIA processors. I have not tested the Intel Fortran compiler, but it seems to be similar to the Intel C++ compiler with respect to CPU dispatching.
Anybody who have earlier versions of the compiler and function libraries than the ones I have tested are welcome to contact me.
|Reply To This Message
|New Intel compiler version - still the same!
|Author: Agner Fog
|Date: 2010-09-22 11:37
A new Intel C++ compiler version 12 has now been released as part of the new "Intel Parallel Composer 2011". The CPU dispatching methods are unchanged from version 11. Apparently, all that has come out of the legal battles over CPU dispatching is a notice on Intel's website that the compiler does not optimize equally for non-Intel microprocessors (see link).
The main difference between version 11 and version 12 of the compiler is that the latter has more features for splitting the code into parallel threads in order to take advantage of multi-core processors. I have not tested how these features work on non-Intel processors.
The settlement with AMD requires that Intel shall not include any Artificial Performance Impairment in any Intel product. I cannot find any change in the new compiler version that reflects this requirement.
While the wording of the AMD settlement with regard to CPU dispatching is much more far-reaching than the FTC settlement, it has had no apparent effect so far, perhaps because it is subject to interpretation. Likewise, the FTC have not succeeded in making Intel change their compiler and libraries - maybe because they don't have the power to do so, or maybe because they don't have sufficient specialized knowledge to counter the technical arguments of Intel's experts.
Anyway, the software community will still have to live with the technical problems. My best advice now is to override Intel's CPU dispatcher as explained in my C++ manual, or use another compiler.
|Reply To This Message
|GCC now has support for function dispatch
|Date: 2010-09-27 11:33
|GCC support for function dispatch has recently been checked in.
More information here:
|Reply To This Message
|Intel compiler question
|Date: 2010-10-11 06:21
|Hello Agner and thank you for sharing all of your wisdom with us, it's really appreciated.
At the time of writing there's the following paragraph in your optimizing software in C++ manual:
"Programs compiled with the Intel compiler with the /Qax option will run sub-optimally on non-Intel processors unless the above patch is included. Programs compiled with the /Qx option will not run at all on non-Intel processors unless the above patch is included."
Does that mean that the unfair CPU path dispatcher is only present when either of those switches are used in the compilation? Or is it present too when using /arch:SSE3 only for example?
Thank you very much for your time, kind regards,
|Reply To This Message
|Intel compiler question
|Author: Agner
|Date: 2010-10-12 02:11
|When the /arch option is specified to the Intel compiler, it will use the SSE2 version of most library functions (bypassing the CPU dispatching in the library) even when a higher instruction set is specified. The default value for /arch is SSE2 in version 11 and 12 of the compiler. The program will run fine on non-Intel processors unless it calls a library function with CPU dispatching, for example in the MKL library. It will not run on any CPU with an instruction set lower than specified by the /arch option.
The /arch:AVX option is unofficial at the moment. /arch:AVX will use the AVX version of some library functions. This doesn't work with non-Intel processors at the moment, but this is a bug which they have promised to fix.
|Reply To This Message
|New Intel compiler version - still the same!
|Date: 2010-11-29 00:59
|Thanks for all of your excellent analysis of the Intel compiler behavior on Intel and AMD hardware.
I wanted to inform you of another alternative to using either the new Intel compiler or the GNU tools for
x86 (Intel and AMD) systems. Sun Microsystems, now part of Oracle, offers a great
developer tool suite... and it is free for both development and production usage.
The Oracle Solaris Studio suite includes C, C++, and Fortran compilers, along with a number of
advanced tools (such as, a dbx debugger and a performance analyzer). All of these tools support
both Intel and AMD hardware via command-line options while the default is an architecture type
of "generic" which tries to balance performance for both chips sets in one binary. It is an impressive
free set of tools and can be downloaded from: www.oracle.com/goto/solarisstudio (even though the
name is *Solaris* Studio, there is a Linux download for it as well). I think you'll find the performance
comparable to, and in some cases, better than(!) the Intel compiler on both the Intel and AMD chip sets.
|Reply To This Message
|New Intel compiler version - still the same!
|Author: Daniel
|Date: 2011-12-23 12:33
|First of all I want to thank you for all your research an work coding a fair dispatcher override concerning Intel's Compiler. Without your work this Compiler wouldn't be usable for me at all because code that favorizes Intel CPU's is inacceptable for me!
I'd like to add, that in version 12 of Intel's C++ Compiler for Windows your dispatcher override code works for 32bit, but not for 64bit. Seems like the x64 equivalent for AVX is smaller than the 32bit number.
Adding a simple switch for 64bit and changing the the value at the line __intel_cpu_indicator = 0x20000; from 0x20000 to 1<<16 for the 64bit branch solves the problem. I'm not sure whether the other values are correct or not because the only AMD CPU I have available supports AVX.
The Code vor the MKL and VML are fine though.
|Reply To This Message
|New Intel compiler version - still the same!
|Author: Agner
|Date: 2011-12-25 04:19
|Daniel wrote:
Seems like the x64 equivalent for AVX is smaller than the 32bit number.Please email me with an example of a function that fails with __intel_cpu_indicator = 0x20000. I will investigate it.
|Reply To This Message
|New Intel compiler version - still the same!
|Date: 2012-02-12 12:39
Looks like the FTC has finished the ruling. If you purchased the Intel compiler you can receive compensation.
Nicely Nicely. I wasn't going to type this entire thing, however it needs to be done.
"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. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimizations on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice."
They hide the text in a gif to avoid the search engines. However this site is indexed very well.
|Reply To This Message
|New Intel compiler version - still the same!
|Date: 2012-03-14 10:50
|I am not sure why Intel used images for that one instance, but their are a number of sites on the Intel web where the announcement is in text format. A quick search for a phrase of the announcement found a number of them in various formats .... PDF, text, image,
I doubt they were hiding anything but it makes good reading.
This is not directly related to the compiler but it does raise the issue of potential problems if there is some difference in the way that Intel and others implement new features. They have updated the BOINC project PRIMEGRID to use the AVX instructions introduced on Sandy Bridge and Bulldozer. The code works fine on a Sandy Bridge part but fails on a Bulldozer.
AVX build of llr (20%-50% faster)
"This has been tested on Intel Sandy Bridge but should also work on AMD Bulldozer [UPDATE] DOES NOT WORK on AMD Bulldozer. Currently, these are the only two CPU's that support AVX. Attention: AVX is supported only after Win7 SP1. WinXP does not have AVX support."
I thought you might be interested.
|Reply To This Message
|Still no library that is optimal on all processors
|Author: Agner
|Date: 2012-04-18 08:52
Choosing the most efficient function library can be a nightmare to a programmer. I have tried to calculate the cosine function with different libraries and compare the calculation time. The best version is 19 times faster than the worst!
AMD have now updated their math libraries and added CPU dispatching. There are two versions of code in AMD's LIBM library: One for the SSE2 instruction set and one for AVX and FMA4. Intel processors will run the inferior SSE2 branch because they don't have the FMA4 instruction set. The incompatibility between Intel's and AMD's FMA instructions is another scandal, which I have discussed in this blog post. The AMD library does not check the CPU brand name as Intel libraries do. It only checks for the FMA4 instructions which are not supported by Intel processors, although - quite ironically - they were designed by Intel. It will be possible to run the better branch on Intel processors if Intel decides to support the FMA4 instruction set in the future.
The following table shows the results of some tests I have made of different math libraries.
The Gnu function library (glibc) uses an outdated and inefficient code. The Microsoft library has decent performance in the 64-bit version, but of course it supports only the Windows platform. Intel's general math library is no better in my test case, but Intel's Short Vector Math Library (SVML) is very good. The SVML library supports vectors of 4 floats in an XMM register (SSE2) or a vector of 8 floats in a YMM register (AVX). It will choose the inferior generic path for non-Intel processors unless we replace Intel's CPU-dispatcher as described above. Intel's libraries are available for both Windows, Linux and Mac. AMD's LIBM library supports vectors of 4 floats. It is available for Windows and Linux, but only in 64-bit mode.
The sad conclusion is that we have no fully optimized math function library that supports all brands of x86 processors and all operating systems. If we want optimal performance on all processors, the best choice is to use Intel's SVML library and manipulate it into treating non-Intel processors better.
It would be nice if more people would work on improving glibc. This library supports all processors and platforms, but it is poorly optimized. Only a few memory and string functions in glibc have CPU dispatching, while the math functions have only old and poorly optimized versions. It would also be nice to have vector versions of the math functions in glibc because the Gnu compiler has support for such functions.
|Reply To This Message
|Still no library that is optimal on all processors
|Author: Guest
|Date: 2012-05-17 11:38
|I know this is an old blog but does anyone have any news on whether Intel has any intention of removing the performance throttle against AMD? Seems Antitrust lawsuits isn't enough, and only when Intel starts having to continually pay fines and compensation will they realise the costs of comensation is crippling them... since most users only care about performance, then use of Intel's compiler which is made to only benefit Intel CPUs is giving Intel an unfair advantage in the market, by costing AMD sales.
I suppose the only way around it is for developers to blacklist and boycott the Intel compilers and move to one that is independant of CPU vendors (i.e. open source or made by the developers themselves) Unfortunately this would cost time, effort and money and would be much easier to use Intel's considering that any such move would probably lead to Intel giving out sponsors or 'bribes' in the same way that AMD and Nvidia do with certain games, when the logo comes up at the start.
Whilst it could be true that Intel generally have better architechture and overall performance vs AMD, they shouldn't have to resort to cheating.
|Reply To This Message
|Still no library that is optimal on all processors
|Author: Agner
|Date: 2012-05-17 13:40
|Guest wrote:
does anyone have any news on whether Intel has any intention of removing the performance throttle against AMD?It's not getting better. The latest version of Intel's SVML (small vector math library) has some functions that can only be called from processors with AVX because the input parameter is an AVX vector (YMM register). There is no logical reason why these functions should have a CPU dispatcher, yet they have two different code paths for the same instruction set: An optimized version for Intel processors with AVX and an inferior version for other brands of CPU with AVX.
|Reply To This Message
|Still no library that is optimal on all processors
|Author: David
|Date: 2012-05-19 16:35
|For the static IPP library, can't a custom dispatcher be built with something like... if not "GenuineIntel" then if cpu reports support for SSE2 / 3 / 4 / etc.. then staticinitcpu(the intelcpu compatible with those instructions)??
Has such a dispatcher already been created by AMD or someone??
|Reply To This Message
|Still no library that is optimal on all processors
|Author: Agner
|Date: 2012-05-20 01:58
|David wrote:
For the static IPP library, can't a custom dispatcher be built...
The IPP has fair CPU dispatching. There is no need for a custom dispatcher here. Dispatchers for the other Intel libraries are described in my C++ manual.
|Reply To This Message
|Still no library that is optimal on all processors
|Date: 2012-06-16 04:45
|Do you have any tips for changing the CPUID using VMWare Workstation 8.0.4? I edited the .vmx file to read (at the top part of the file) -
.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "8"
numvcpus = "4"
cpuid.coresPerSocket = "4"
scsi0.present = "TRUE"
memsize = "4096"
The VM boots up and at the first screen of Win XP install when it says in the bottom grey bar "Setup is startng Windows"
|Reply To This Message
|Still no library that is optimal on all processors
|Date: 2013-05-20 18:05
|Open-source Yeppp! library (www.yeppp.info) provides vector mathematical functions optimized for both Intel and AMD processors, and demonstrates performance comparable to the best vendor-optimized libraries: www.yeppp.info/home/yeppp-performance-numbers
|Reply To This Message
|Still no library that is optimal on all processors
|Author: Agner
|Date: 2013-05-21 07:22
|Marat Dukhan wrote:
Open-source Yeppp! library (www.yeppp.info) provides vector mathematical functions optimized for both Intel and AMD processors, and demonstrates performance comparable to the best vendor-optimized libraries: www.yeppp.info/home/yeppp-performance-numbersThank you. That is good news indeed. I hope that you will add more functions to the library.
|Reply To This Message
|This is still going on, wow just wow
|Author: Vuurdraak
|Date: 2016-11-10 12:30
|I knew Intel was doing this stuff in the past, I didn't realize they where still crippling their compilers.
I'm not a professional coder so I never looked at it again, I am how ever a long time AMD CPU user, who Intel is hurting on purpose.
I checked on the Intel website and the notice that they only optimize for Intel processors is still there, so they are still crippling their compilers, ten years after Agner started to complain to Intel.
I'm surprised that no anti-trust authorities have slammed Intel for this, as to me it is clearly anti competitiveness coding.
There should be no reason at all to attempt to detect the CPU's brand other then to hurt the competition, even if this needs to be done to exclude bugged CPU models, any branching done that automatically eliminates non-Intel CPU's from a faster code path before checking if you are dealing with a bugged CPU or it's feature set, clearly is done on purpose.
If Intel was some small business, that was struggling for market share, then I would not care too much, but they are a monopolist who produces current products that are more expensive for the same speed as what I paid for my Phenom II CPU five years ago, because there is almost no competition, also hurting the people who buy Intel CPU's as Intel can jack up the price.
While Microsoft was forced by the EU to include competitors browsers as a choice in to it's OS, Intel is allowed to purposefully code compilers that are widely used due to their great optimization, to slowdown competitors products, it's just amazing.
|Reply To This Message
|This is still going on, wow just wow
|Author: Agner
|Date: 2016-11-10 13:22
|Vuurdraak wrote:
I'm surprised that no anti-trust authorities have slammed Intel for this, as to me it is clearly anti competitiveness coding.See www.agner.org/optimize/blog/read.php?i=49#112
BTW, here is more evidence that benchmarks have been corrupted:
|Reply To This Message
|This is still going on, wow just wow
|Author: Vuurdraak
|Date: 2016-11-11 04:34
|I did read the FTC and AMD court case part, I'm not a lawyer, but has this made it impossible to go after Intels compilers in the USA ?
Apart from paying some cash to AMD and promising not to hurt AMD, they never stopped crippling the compiler, and I'm wondering what kind of non-techies have allowed this to continue, because anybody who has ever written a piece of code, understands that this compiler stuff is done on purpose and is unnecessary, they do not have to explicitly optimize for non-Intel CPUs to allow non Intel CPUs to take the best possible code path, the only thing they need to do, is not kill a CPU code path based on the CPUs brand name.
The EU is still in a court case with Intel, although that seems to be about giving rebates to Dell, HP, NEC & Lenovo, for not selling AMD products: fortune.com/2016/10/20/intel-eu-antitrust-fine/
|Reply To This Message
|This is still going on, wow just wow
|Date: 2017-01-02 10:35
|Hello! I am justa simple user. And more than 15 years I am using AMD CPU becpuse I just want to help to the company to make a real competition and not to be Intel as monopolist.
Is it possible to make some software to destroy a "check" of genuine intel?
Exist 1 software with name - Intel Compiler Patcher ori cc_patch here is link - https://cloud.mail.ru/public/GMpC/YQJ6spHtQ
Is it possible to modify it to make it more usefull at 2017?
Or maybe exist something else?
dear Agner, you have a great program cpuidfake that working Only with VIA. Can you make that it will work with AMD in 2017 reality ?
Sorry I am just a simple user. But I am hope that it possible. thank you for your work!
|Reply To This Message
|This is still going on, wow just wow
|Author: Agner
|Date: 2017-01-02 11:35
|Denis wrote:
software with name - Intel Compiler Patcher ori cc_patch here is link - https://cloud.mail.ru/public/GMpC/YQJ6spHtQI haven't tried the russian patcher. You may try it at your own risk - but be sure to backup your programs first!
Agner, you have a great program cpuidfake that working Only with VIA. Can you make that it will work with AMD in 2017Unfortunately, it is not so simple to modify the CPUID on an AMD machine.
|Reply To This Message
|Threaded View
|List Messageboards


text:
Invite: Mardi GrasMonday, February 19th, 2007
Holidays on the Net invites you to our Mardi Gras party at "Mardi Gras on the Net."
Mardi Gras is a traditional holiday celebrated in many
of the southern states of the USA. The most famous celebration
takes place in New Orleans, Louisiana. It is celebrated with
parades, "beads, doubloons, and trinkets", masquerade balls and
King Cakes.
So join Holidays on the Net as we share this holiday
with you. We have the history behind Mardi Gras, pictures of
floats, crafts, coloring sheets, books, and a recipe to make
your own "King Cake"!
This year Mardi Gras is celebrated Tuesday, February 20th.

subset: commoncrawl


text:
Home Remedies for Restless Legs Syndrome
Enlarged Prostate (BPH)
Pet Health
Stages of Pregnancy
First Aid
See All Slideshows
Sleep Late
Restless legs syndrome, also called RLS, makes it hard to sleep. Your legs may ache, burn, tingle, twitch, or jerk. To get the deep sleep you need, try going to bed a little later and sleeping later in the morning. Those morning hours may be some of your best rest.
Keep a Regular Bedtime
Going to sleep and waking up at the about the same time every day helps just about everyone sleep better. When you have RLS, it may stop a bad cycle where fatigue makes your symptoms worse, and then the twitching and tingling ruins your sleep for another night. Pay attention to how much sleep you need to feel your best. Most adults need seven to nine hours each night.
Stretch Before You Sleep
Gentle stretching before bed might help. For a calf stretch, step forward and bend your front leg while keeping your back leg straight, in a small lunge. You can put your hand on a wall for support. Repeat on the other side. Stretching also helps if you've been sitting for a long time.
Cut the Caffeine
Coffee, tea, chocolate, and cola can all give you a little burst of energy, thanks to the caffeine, but they can also make your RLS symptoms worse, even hours later. Cut out this stimulant and you may find it easier to fall asleep and stay asleep. If you cut down, keep in mind that caffeine can affect some people for as long as 12 hours.
Soak in a Warm Bath
A warm bath before bedtime relaxes you and makes it easier to fall asleep. So it's probably not surprising that this classic way to wind down also reduces the symptoms of RLS.
Chill or Warm Your Legs
Heating pad or ice pack? Go with whatever feels good. Either change in temperature can be soothing. Some people say a cold shower works best.
Make Exercise a Habit
Moderate exercise during the day pays off with better sleep at night. Walk, jog, lift weights, or find any exercise you enjoy. One study found that exercise led to less leg movement and longer and deeper sleep for people with RLS. Be careful not to overdo it. Intense exercise or working out just before bedtime could make your symptoms worse.
Exercise Your Brain
Sitting still can trigger RLS symptoms, such as when you sit down in the evening to watch TV or you're stuck on a crowded bus. Activities that distract your mind can sometimes ease your symptoms. Work a crossword puzzle, read a great book, or play a video game.
Move Your Legs
When your legs ache or twitch, moving them may ease those uncomfortable feelings. Sometimes just shaking or moving your legs can help. Choose an aisle seat in a movie theater or airplane so you can get up easily.
Breathe Deeply
Stress makes RLS symptoms worse. Release the tension by taking slow, deep breaths. It also helps to dim the lights and listen to soothing music before you go to bed.
Massage Your Legs
A calf massage before bed might calm your RLS symptoms and help you get to sleep. You can do it yourself or trade mini-massages with a family member. Give your partner a 10-minute shoulder rub, then stretch out for a leg massage and relax deeply.
Ease Into a Yoga Pose
Yoga combines three remedies that can reduce mild RLS symptoms: stretching, deep breathing, and relaxation. Try a class or video to learn the right posture and pace for each move. Once you know the poses, you can do them on your own. A podcast can lead you through the moves and include an eyes-closed, guided relaxation at the end.
Turn Off the TV Before Bed
Watching television or using the computer just before bed can make it harder to fall asleep. Sleep experts say you should make the bedroom a TV- and computer-free zone.
Avoid Alcohol and Cigarettes
Alcohol and cigarettes can bring on the symptoms of RLS and harm your sleep in other ways, too. A drink may make you drowsy at first, but you're more likely to wake up during the night or have poor sleep that doesn't leave you feeling rested. The nicotine in cigarettes is what triggers RLS symptoms, so avoid cigars, "chew," and any other tobacco products.
Ask About Iron Supplements
People with RLS often have low levels of iron in their blood. Your body needs iron to make dopamine, a brain chemical that helps control movement. Ask your doctor whether an iron supplement might help you. If so, take it with a glass of orange juice or another source of vitamin C to help your body absorb the iron.
Review Your Medicines
Some cold and allergy drugs can trigger RLS symptoms, especially some antihistamines. Some antidepressants and drugs to treat nausea can also cause the same problem. Tell your doctor about all medicines and supplements you take. There may be another drug you can take that won't trigger your RLS symptoms.
Related Slideshows on RLS
Related Slideshows
Reviewed by Carol DerSarkissian on Tuesday, December 06, 2016
RLS Remedies in Pictures: Home Care for Better Sleep
This tool does not provide medical advice. See additional information:
© 2005-2017 WebMD, LLC. All rights reserved.
Source slideshow on WebMD


text:
With traffic congestion at record levels and more vehicles added to Texas roadways daily, TxDOT understands that public transportation is a vital part of the state's future. Getting people out of cars and onto buses and metrorail trains can reduce travel time and increase the quality of life for Texas travelers.
TxDOT provides grants to cities and municipalities to encourage and support public transportation. We work with the Federal Transit Administration, non-profits, and local government entities to promote the use and development of public transportation throughout the state. Under TxDOT's oversight, public transportation will continue to play an increasing part in getting Texans where they need to go.
Public transportation is available not only in cities, but in many rural areas as well. Use our Find a Ride feature to identify public transportation options in your area. For more information, visit our Public Transportation Division page.


text:
Women's Beach Duo have Strong Finish to 2013 FIVB SeasonCanada's beach pair of Jamie Lynn Broder and Kristina Valjas closed out their FIVB season with a third straight 9th place finish and look to keep that momentum going forward. The duo played a total of 12 FIVB Grand Slam and Open events in 2013, with four top 10 finishes. Broder, the 28 year old from Victoria, and Valjas, 26 from Toronto, have been playing together for two years now and their success is growing.
The pair played their final three tournaments at the Sao Paulo Grand Slam in Brazil, the Xiamen Grand Slam in China, and the Phuket Open in Thailand. They advanced to the second round of playoffs and placed ninth in all of these tournaments, their highest placement in any Grand Slam or Open event. They entered the final tournament in Phuket with the 12th seed thanks to their success in Brazil and China, but fell to the 13th seed Argentineans in two sets.
"Kristina and I are really proud of the way we wrapped up the end of the FIVB season with three 9th place finishes in a row. We were tested by the elements in China with extreme wind, and Thailand with extreme heat, but we worked together and found a way to fight through. We are excited to continue building on these results next year on tour." said Broder of their 2013 season.
The pair may be done with FIVB competitions for this year, but there is still volleyball to be played. The Hilton Beach Volleyball Exhibition is taking place mid-November in Hawaii, and the NORCECA Finals get underway November 27th in Trinidad & Tobago. These will be the last two events of 2013 for the team of Broder and Valjas as they prepare themselves for 2014.
For more information on FIVB beach events, please visit http://www.fivb.org/EN/BeachVolleyball/


text:
New Balance 877 Training Shoe - Mens
Sorry, this item is sold out!
Looks like you've got more shoe shopping to do - have fun!
Looks like you've got more shoe shopping to do - have fun!
Item # 257853
Well, if you enjoyed the New Balance® 813, you will fall in love with the 877. New Balance® has taken it's popular cross trainer and perfected it. A slipper-like fit and stretch upper to allow for a natural movement this shoe is perfect for any gym or cross training activity. A durable pivot point outsole makes it easy for you to stay stable and a multi-density insert for cardio comfort, exercise with cushioning and style.
- Synthetic upper
- Stretch quarter
- Multi-density insert for superior cushioning all day long
- Rubber, pivot point outsole
- Imported
- View More New Balance
By: MG53562
Location: Middleton, WI
January 18, 2013
Pretty decent
"While my toes still get a little tingly when I work out on my elliptical it is a major improvement from my cross trainers."
Click anywhere to close this.


text:
By PATSY STODDARDEditor
Apprentice Artists from the Utah Symphony and Opera Company were in Emery County recently performing at the schools and senior citizen centers. They also presented a public concert, "Sing the Night Away" on Feb. 13 at the Emery High Auditorium.
The Ensemble has been on tour throughout the Intermountain West performing for all age groups and introducing them to the world of opera. They have chosen the "Operalympics" as the way to introduce the art form to young students. The older students were also experiences."
Thurman said, "We receive training with the opera company. We work on our languages and stage deportment. We are coached on music and styles. We really work hard on the languages to make sure the pronunciation is correct because the opera uses many languages. We also work with the opera professionals in master classes where we are tutored by more experienced opera performers."
Richter said, "We are working to polish what we learned in school and put it into practice. This is like the end of our study period and before our careers in opera."
Thurman said, "Working with the kids is fun but it can be tiring. It is good training to perform 5-7 days straight it builds stamina. The workshops we hold for the students teaches them a bit about communicating with music and how we use makeup, props and other things. This is a different musical experience for many of the students. Many of them have never been to an opera before."
One of the workshops which Richter helps with teach the children how to behave as an audience member at an opera. They learn the differences in behavior between a basketball game and an opera performance. "These are good experiences for the students," said Richter.
Thurman said, "One of the Huntington students came up to me after the performance and said this was the first time she had heard opera and said, 'Now, I'm a fan.' We work to dispel the myth that opera is boring. Opera is not boring."
Cilli described the career of an opera performer as a freelance career. They have many auditions for many different opera companies. Sometimes you are gone for three weeks at a time or two months. They spend a lot of time moving around. Each opera has their performing season. The performers described the opera life as being difficult for a family. They must work hard to carry on distance relationships. Richter described a Dear John email he received from a girl friend when he had been performing with an opera company and was into his contract, "She couldn't take it." But, Richter also described a lot of opera performers who do have families and make it work. "They are committed to balance their careers and their families. After you have been into your career for a while, you can pick and choose your performances. But, right now we're too young for that and we just take what we can get," Richter said.
Firenze said, "The costuming is fun and we get to dress up for fun. It keeps us youthful. We can play around and get paid for it. I love performing, it's fun. But, an opera career also requires a lot of dedication.....it's hard to do this."
Richter teased that, "We couldn't hold a real job, so we're singing for a living."
Cilli commented, "It's not easy. At auditions you are competing against hundreds of people you know. But, I have to do this. I have a need to do it. It's always been my first choice."
Thurman said, "Music has always been there. I would put on shows for my mom and her friends. I was always writing songs and singing."
Richter said, "I always wanted to be a baseball player. I tried out for professional teams but I wasn't fast enough. I received one recruiting letter, but decided I probably wouldn't make it so I jumped into music in college. I played both sports and was involved in music in high school. But, since I was better at music than baseball, I have stuck with my music."
Thurman said, "There is a serious side to all of this. We are looking at refining our skills and getting better at what we do. There are multiple aspects to opera. All of the training and languages...... it takes a lot of commitment to become fluent in French, Russian, German, Italian and English. The training of a voice is an abstract thing. Learning to make it sound a particular way. We are always learning and it can be frustrating sometimes. We are always trying to perform and polish our skills. That aspect of opera is always there."
Richter said, "It's all about keeping it fun too. There are many performers who still sing into their 70s and just get better. It is a constant learning process."
Perry said, "We're all serious about our music and feel the same way about constantly learning and improving."
These young apprentices have a long list of accomplishments even though it is early in their careers. Cilli has graduated with a bachelor's degree from Stetson University and a master's at the New England Conservatory. He performed with the apprentice program in Iowa and has also had roles in Gianni Schicchi, Figaro in The Marriage of Figaro, Sid in Albert Herring, Sultan Achmet in Canslide and Maestro in Vina La Mama.
Firenze has participated in the Utah Festival Opera Young Artist Program. She performed roles as second lady in The Magic Flute, Ethel in Desert Song and the Baroness in The Sound of Music. She earned her bachelor's degree in voice at McGill University and her Master of Music at the Manhattan School of Music. She furthered her training at the Bel Canto Northwest Festival, Tanglewood Music Center, Israel Vocal Arts Institute and the American Institute for Musical Studies in Graz, Austria. She also performed as a member of the Metropolitan Opera Guild Outreach Program. She has played Dinah and also Suor Cercatrice in Suor Angelica.
Perry is the pianist for the Ensemble. She completed a Doctor of Musical Arts degree in piano performance at the University of Arizona. She has performed in concerts and festivals throughout the western U.S. and Italy where she did her dissertation research on 20th century Italian piano music. She is a two-time recipient of the Medici Scholars award and is active as vocal and instrumental accompanists and as a piano teacher. She earned her bachelor and master of music degrees from Brigham Young University.
Richter was recently an apprentice with Des Moines Metro Opera where he performed the roles of Emperor Altoum in Turandot and the First Jew in Salome on the main stage. He has also participated in the apprentice programs at Utah Festival Opera and Central City Opera. He performed the roles of Master of Ceremonies in Gloriana and Parpignol in La Boheme as well as Larry/Matt in Face on the Barroom Floor. He was the winner of the Nebraska District of the Metropolitan Opera Auditions and also honorable mention at the upper Mid-West Regional MET. Upcoming roles include Giles Corey in The Crucible and Bardolfo in Falstaff for Des Moines Metro Opera in 2003.
Thurman was in residence at Natchez Opera Festival, recently where she sang the role of Pauline in Toy Shop and covered Valencienne in The Merry Widow. Other credits include Suor Dolcina in Suor Angelica with Des Moines Metro Opera, and Suor Genovieffa in the same work with the Aspen Opera Theater Center. She also has played the role of Sister Suzanna in the world premier of Bernard Rands' opera, Belladonna. She has also performed as Adele in Die Fledermaus, Pamina in The Magic Flute, Lauretta in Gianni Schicchi, and Sandmannchen in Hansel and Gretel. Thurman earned her bachelor's degree in music at Oklahoma City University and her masters's at the Cincinnati Conservatory of Music.


text:
Access Library Materials Off-Campus
- How do I find materials on my topic?
- How do I request materials?
- What does it cost?
- How long does it take?
- How long can I keep the books?
- What are my alternatives to borrowing through the Hartzler Library?
- Who do I contact for further information?
How do I find materials on my topic?
For access to materials in the Hartzler Library search Sadie, the online catalog. The catalog includes several thousand NetLibrary ebooks accessible online.
The Hartzler Library provides access to a variety of online databases which include listings of journal articles, reference information and a listing of materials held by libraries worldwide. Many of these databases also provide access to the full-text of journal articles.
Several databases cover a wide range of disciplines and can be a good place to start a research project. They include EBSCOhost's Academic Search Complete (ASC), the Gale databases and Wiley-Blackwell. ASC and Gale index over 30,000 journals and provide full-text to over 15,000 titles. Wiley-Blackwell provides online access to over 750 journals published by Blackwell.
Many databases are subject-specific and provide citations as well as full-text to appropriate journal literature for a specific discipline. Subject guides for each discipline provide access to appropriate databases.
EMU uses a proxy server to authenticate for off-campus access to the research databases as well as NetLibrary ebooks. Your Royal Username and Password are used to log in to the proxy server. If you do not have a Royal Username and Password, either contact your program director or the library.
How do I request materials?
All circulating materials located in the Hartzler Library are available to students currently enrolled in off-campus programs. You may also request articles from periodicals owned by the Hartzler Library as well as books and articles from other libraries.
For circulating materials in the Hartzler Library:
- In Sadie, the online catalog, search the item you want and display it.
- Click the "I Need Material" link.
- Click "Off Campus Student Requests."
- The call number and barcode are already filled in.
- If the record has multiple volumes, only the first item will be listed. Use the notes field if you want a different item.
- Enter your EMU ID number and click the "Place Request" button.
For periodical articles in the Hartzler Library and materials from other libraries: Interlibrary Loan (ILL)
- Please submit all interlibrary loan requests electronically through ILLiad.
- The library uses LinkSource, an OpenURL resolver which links from a citation in one database to the full-text in another database. If no full-text options are available, LinkSource provides an ILL form instead, look for the "Request this item through interlibrary loan (ILLiad)". Patrons will need to login to ILLiad with their Royal username and password.
- There are blank ILL forms in ILLiad as well.
- Submitting requests other ways will delay processing.
What does it cost?
There is no charge for any materials owned by the Hartzler Library. Generally there are no charges to the patron for interlibrary loan material.
How long does it take?
We will process requests placed through Sadie on the next work day (Monday-Friday). We use a variety of methods to ship materials to you including courier service to Lancaster, US mail, and electronic document delivery. For Lancaster students, all materials except articles will be shipped to the Lancaster site, not directly to you.
Interlibrary loan materials can take from one day to two weeks to be delivered to the Hartzler Library and then additional time to get to the requester.
How long can I keep the books?
- Hartzler Library materials:
- Books are checked out to you for six weeks. You may renew books as long as no one else is requesting them. You are expected to return books to the Lancaster site or the Hartzler Library by the due date. Overdue notices will be emailed to you. Fines are twenty-five cents per day, with a maximum of $5.00.
- Interlibrary loan materials:
- The due date is set by the lending library and is indicated on the wrap around the front cover of the book. Loan periods generally vary from 4-8 weeks. Return all materials to the Lancaster site or the Hartzler Library. Do NOT return them to the lending library.
What are my alternatives to borrowing through the Hartzler Library?
EMU at Lancaster
Students in the Eastern Mennonite Seminary programs at Lancaster may use the libraries at Lancaster Theological Seminary, Lancaster Mennonite Historical Society, and Biblical Seminary, Hatfield, PA.
There are several academic libraries in the Lancaster area which allow members of the community to use their libraries, usually with annual fees for circulation privileges:
- Elizabethtown College, High Library
- Franklin and Marshall College, Shadek-Fackenthal Library
- Millersville State University, Ganser Library
- Pennsylvania State University York Campus, Penn State York Library
You may find it quicker to use the Interlibrary Loan service at your local library. Pennsylvania residents should check into the Access Pennsylvania program at your local public library. "Access Pennsylvania" enables use of participating libraries statewide. Larger public libraries or participating academic libraries usually are able to provide better ILL services.
Students taking Online Courses
You may find it easier to access research materials at a local library. For those taking courses from EMS, libraries at schools who are members of The Association of Theological Schools might prove helpful.
Who do I contact for further information?
Please contact us if you need assistance!


text:
|Note: These balls do not qualify for free shipping. Only ships within the continental United States.
These orange felt balls are recommended for kids ages 9-10. They are the same size as standard tennis balls, but they are low compression, resulting in a slower bounce than a regular tennis ball.


text:
Express black shorts from Pretty Little Liars seen with Aria Montgomery (Lucy Hale)
As Seen on Aria Montgomery (Lucy Hale) in Pretty Little Liars - Season 6 Episode 1
Aria Montgomery (Lucy Hale) is seen with the black Express Mid Rise Lace-Up Denim Shorts in Pretty Little Liars, Season 6, Episode 1 - Game On, Charles. Find Shorts, Clothing and Women's Fashion from Pretty Little Liars below.
In the hit show Pretty Little Liars, Aria Montgomery (Lucy Hale) might be decked out in satin prom couture and designer rags, but she's ready to fight dirty when it comes to taking down her tormentor, the mysterious "A." As the pressure builds in Season 6, one thing is for certain—never trust a pretty girl with an ugly secret.
Comments and Suggested Matches
Add a comment:How do I add links/pictures?
Suggest a product match (optional):
Suggest a Product Match
Select Image | Use an Image Link
Image Link:
Product Name:
Price: (optional)
Match Type:
Tell us how you know this is an exact match:
Select a size and copy the HTML above to embed this interactive movie frame into your website!×


text:
Cottonwood Creek Consolidated Irrigation Co has received a request
from Cornelius Development Corporation who asserts that Share
Certificate No's 1117, 1118. and 1151 for 12.00, 3.00 and 5.00 share
respectively in the Company have been lost, destroyed, or stolen and
that they are the rightful owners of these certificates. An interested
person may file a written notice of objection with the Company
explaining why a replacement certificate should not be issued. Unless
the Company receives a written notice of objection within sixty (60)
days of this notice, replacement certificates will be issued as
requested and the original share certificates will be permanently
canceled on the record of the Company.
Published in the Emery County Progress February 19, 26 and March 5,


text:
We support and enjoy that Sparta, Wisconsin has businesses that "Grow Local and Buy Local". At the Franklin Victorian Bed & Breakfast we love to shop and send our guests to this business. We will highlight one business in the post. "Northwood Country Market". One of many Unique Stores in the Area. Northwood Country Market is Owned & Operated by the Kilmer Family, Since 2001.
- Large selection of Organic and Gluten Free Foods
- Over 30 Kinds of Cheese, you can purchase sliced or chunked
- Large selection of Deli Meats, Cut to your specifications
- They are known for their choice beef and other fresh meats
Bulk foods galore! Candy, nuts, snacks, dried fruit, spices, Pastas and More!
In many seasons they offer locally grown produce, seasonal fruits by the case.
Please make sure to add this business to your plans when visiting our area.
1003 W. Wisconsin ST
Sparta, WI 54656
Open Monday thru Sat. , closed Sunday


text:
Duck Head Wyatt Boys Toddler & Youth Western Boot
Sorry, this item is sold out!
Looks like you've got more shoe shopping to do - have fun!
Looks like you've got more shoe shopping to do - have fun!
Item # 233446
Saddle up your little cowboy in the Duck Head Wyatt. This western inspired, rugged boot is just what he needs.
- Synthetic upper with western stitching
- 8" shaft height, pull on
- Rubber sole
- Imported
- Online Exclusive!
By: Trewdesigns
Location: Saint Louis
April 25, 2013
Buy the Correct Size!
"I bought these in a size too big for my son thinking he could just grow into them. Well he was so enthusiastic about wearing them and running in them like crazy, they have completly fallen apart! Done in one month!! But I do feel that if they would have fit properly they would have lasted longer, but not much longer. The material is pretty cheap, so keep in mind you get what you pay for. But either way, he loved them and they were the talk of all his classmates :)"
Click anywhere to close this.