If you and AMD have documented the approved process so carefully, why do you only allow 'GenuineIntel' chips to pass through and have their capabilities detected and not 'AuthenticAMD' ones? This still smacks of deliberate crippling of performance on any chips but your own. If all else fails, just document that code compiled with the -ax flags may fail on certain very obscure old CPUs and be done with it.
I run a computing farm with mixed PIII, P4, Core 2 Duo, Athlon MP and Opteron CPUs in it. How should I compile my code to work in that environment such that the optimal CPU capabilities are used on each CPU?
No, that's simply not true. The only check the patch bypasses is the 'is the CPUID GenuineIntel?' one: I don't bypass any of the 'is CPUID supported? What is the maximum level of CPUID supported? What instruction set flags are set?' tests.
The 'who made this CPU' test is completely irrelevant to all of this: I challenge you to name a CPU for which the _cpu_indicator_init function (or equivalent) would give incorrect results if the vendor ID string check was removed.
Now, I haven't looked at the 10.0 compilers yet, so it's possible that Intel have removed all this naughtiness in that release. However, given that I first complained to Intel about this "feature" back in version 7.1, and it remained in place for versions 8 and 9, I'm not holding my breath.
Checking for 'GenuineIntel' is fine, but the actual code emitted by the compiler goes straight to 'no additional capabilities' if it detects any other string. In other words, in the 32-bit compiler any non-intel chip is doomed to run the 'you are a bog-standard 386 with no MMX/SSE/SSE2 support' code path regardless of its actual capabilities. This 'feature' makes less difference in the 64-bit compiler (because the base level is a EM64T with SSE2, as opposed to a 386 with nothing for the 32-bit version), but as new instruction sets come online (SSE3, SSE4 and the like) this artificial crippling of AMD chips will start to show there as well.
And yes, you say you 'tell it like it is', but I've disassembled the actual code and it doesn't accord with your story. See http://www.swallowtail.org/naughty-intel.html for the gory details. The proof of the pudding is in the eating: if you patch one of our programs compiled with the Intel compiler to remove the Intel check it runs significantly slower on AMD chips (as in DOUBLE the runtime).
There is no technical reason for these checks to be there: they are purely a competitive ploy to cripple performance on AMD chips. If Intel released their compiler for free, then I'd say so what: they're allowed to make it a marketing tool. OTOH, they release it as a commercial product and charge me money for it: doing that and then deliberately crippling its performance is IMHO not acceptable.
The Oxford group's technique is looking at a different problem: small molecule 3D shape matching. Surprisingly, this is actually harder than protein shape matching: proteins have a defined 3D shape, but small molecules are flexible and can a variety of shapes. So, you either need to have a flexible fitting method, or you need to enumerate 'example' shapes for each molecule you want to search against.
Compare your search against ~17K protein structures to a search across the roughly 4 million commercially-available compounds, each with 100 example conformations stored. You can see why algorithm speed becomes an issue.
Firstly, only some families of proteins have any x-ray structural data about them: there are whole families that are effectively uncrystallisable.
Secondly, the protein's 3D shape is only half the battle. Small molecules are generally highly flexible, so to search them in 3D you need to enumerate their potential shapes first. That's not trivial for large sets of compounds.
No, completely wrong, I'm afraid:). The context here is virtual screening in drug discovery: you either have a protein cavity of known shape or you have a known inhibitor of a protein in an (either known or modelled) bound conformation. The question is "Which other molecules could fit the cavity?".
The problem is that molecules are flexible. The average drug-size molecule has 6-10 rotatable bonds, and anywhere from 50 to several thousand different plausible 3D shapes. Crystallographic data from the CSD doesn't help: that tells you what structure each molecule takes up in a solid crystal, which will be completely unrelated to the shape it may adopt inside a protein active site.
You mention QM programs: these are still quite a few orders of magnitude too slow to do conformation searches on databases drug-sized molecules. There are programs to do this using classical models, but all of them have issues, and the size of the databases becomes an issue. We (http://www.cresset-bmd.com/) have an in-house database holding up to 50 conformations on 4 million molecules: this is heading towards a terabyte of data and took a reasonable-sized Linux cluster a month to generate. That database is simply all of the compounds you could buy: if you wanted instead to search all compounds you could plausibly make in 2 reactive steps from commercially-available reagents you'd have a database with more than 10^20 compounds.
Maybe they did. Care to estimate the cost to France of French involvement in the American War of Independence? What about the price the Soviet Union paid in winning World War 2? Historical 'yeah but you owe us more' willy-waving is a dangerous game, especially if your willy isn't as big as you think it is.
I released XQuest back in 1994-ish. The gameplay was vaguely similar to Crystal Quest, but the graphics, sound etc were all original. Buckland claimed I'd violated his copyright and asked me to pull the game. I played nice and changed aspects of the game that he'd claimed were too similar to Crystal Quest but he still waved copyright-infringement threats at me and demanded I stop distributing XQuest.
Eventually I called his bluff and he gave up, but the whole experience left a bit of a bitter taste. Interesting to see that he's now made some more money from the franchise...
I'm the author of XQuest. I've been tempted several times to do an up-to-date port, but (a) I've got a family and hence no time, and (b) the original was written in a mixture of Turbo Pascal and assembly language, so it would have to be more like a complete rewrite rather than a port.
The source is available, so if anyone wants to port and/or rewrite it I'd be more than happy to let them do so under the GPL or similar.
It's probably worth mentioning that the original doesn't work under W2K or XP, but works fine in a DOS emulator (such as DosBox).
Slashdot Mirror
If you and AMD have documented the approved process so carefully, why do you only allow 'GenuineIntel' chips to pass through and have their capabilities detected and not 'AuthenticAMD' ones? This still smacks of deliberate crippling of performance on any chips but your own. If all else fails, just document that code compiled with the -ax flags may fail on certain very obscure old CPUs and be done with it.
I run a computing farm with mixed PIII, P4, Core 2 Duo, Athlon MP and Opteron CPUs in it. How should I compile my code to work in that environment such that the optimal CPU capabilities are used on each CPU?
No, that's simply not true. The only check the patch bypasses is the 'is the CPUID GenuineIntel?' one: I don't bypass any of the 'is CPUID supported? What is the maximum level of CPUID supported? What instruction set flags are set?' tests.
The 'who made this CPU' test is completely irrelevant to all of this: I challenge you to name a CPU for which the _cpu_indicator_init function (or equivalent) would give incorrect results if the vendor ID string check was removed.
Now, I haven't looked at the 10.0 compilers yet, so it's possible that Intel have removed all this naughtiness in that release. However, given that I first complained to Intel about this "feature" back in version 7.1, and it remained in place for versions 8 and 9, I'm not holding my breath.
Checking for 'GenuineIntel' is fine, but the actual code emitted by the compiler goes straight to 'no additional capabilities' if it detects any other string. In other words, in the 32-bit compiler any non-intel chip is doomed to run the 'you are a bog-standard 386 with no MMX/SSE/SSE2 support' code path regardless of its actual capabilities. This 'feature' makes less difference in the 64-bit compiler (because the base level is a EM64T with SSE2, as opposed to a 386 with nothing for the 32-bit version), but as new instruction sets come online (SSE3, SSE4 and the like) this artificial crippling of AMD chips will start to show there as well.
And yes, you say you 'tell it like it is', but I've disassembled the actual code and it doesn't accord with your story. See http://www.swallowtail.org/naughty-intel.html for the gory details. The proof of the pudding is in the eating: if you patch one of our programs compiled with the Intel compiler to remove the Intel check it runs significantly slower on AMD chips (as in DOUBLE the runtime).
There is no technical reason for these checks to be there: they are purely a competitive ploy to cripple performance on AMD chips. If Intel released their compiler for free, then I'd say so what: they're allowed to make it a marketing tool. OTOH, they release it as a commercial product and charge me money for it: doing that and then deliberately crippling its performance is IMHO not acceptable.
The Oxford group's technique is looking at a different problem: small molecule 3D shape matching. Surprisingly, this is actually harder than protein shape matching: proteins have a defined 3D shape, but small molecules are flexible and can a variety of shapes. So, you either need to have a flexible fitting method, or you need to enumerate 'example' shapes for each molecule you want to search against.
Compare your search against ~17K protein structures to a search across the roughly 4 million commercially-available compounds, each with 100 example conformations stored. You can see why algorithm speed becomes an issue.
Firstly, only some families of proteins have any x-ray structural data about them: there are whole families that are effectively uncrystallisable.
Secondly, the protein's 3D shape is only half the battle. Small molecules are generally highly flexible, so to search them in 3D you need to enumerate their potential shapes first. That's not trivial for large sets of compounds.
No, completely wrong, I'm afraid :). The context here is virtual screening in drug discovery: you either have a protein cavity of known shape or you have a known inhibitor of a protein in an (either known or modelled) bound conformation. The question is "Which other molecules could fit the cavity?".
The problem is that molecules are flexible. The average drug-size molecule has 6-10 rotatable bonds, and anywhere from 50 to several thousand different plausible 3D shapes. Crystallographic data from the CSD doesn't help: that tells you what structure each molecule takes up in a solid crystal, which will be completely unrelated to the shape it may adopt inside a protein active site.
You mention QM programs: these are still quite a few orders of magnitude too slow to do conformation searches on databases drug-sized molecules. There are programs to do this using classical models, but all of them have issues, and the size of the databases becomes an issue. We (http://www.cresset-bmd.com/) have an in-house database holding up to 50 conformations on 4 million molecules: this is heading towards a terabyte of data and took a reasonable-sized Linux cluster a month to generate. That database is simply all of the compounds you could buy: if you wanted instead to search all compounds you could plausibly make in 2 reactive steps from commercially-available reagents you'd have a database with more than 10^20 compounds.
Maybe they did. Care to estimate the cost to France of French involvement in the American War of Independence? What about the price the Soviet Union paid in winning World War 2? Historical 'yeah but you owe us more' willy-waving is a dangerous game, especially if your willy isn't as big as you think it is.
OK, got me there. They weren't copied from Crystal Quest, though :).
I released XQuest back in 1994-ish. The gameplay was vaguely similar to Crystal Quest, but the graphics, sound etc were all original. Buckland claimed I'd violated his copyright and asked me to pull the game. I played nice and changed aspects of the game that he'd claimed were too similar to Crystal Quest but he still waved copyright-infringement threats at me and demanded I stop distributing XQuest.
Eventually I called his bluff and he gave up, but the whole experience left a bit of a bitter taste. Interesting to see that he's now made some more money from the franchise...
I always thought that XQuest was even better than Crystal Quest, but then I'm biased :).
I'm the author of XQuest. I've been tempted several times to do an up-to-date port, but (a) I've got a family and hence no time, and (b) the original was written in a mixture of Turbo Pascal and assembly language, so it would have to be more like a complete rewrite rather than a port. The source is available, so if anyone wants to port and/or rewrite it I'd be more than happy to let them do so under the GPL or similar.
It's probably worth mentioning that the original doesn't work under W2K or XP, but works fine in a DOS emulator (such as DosBox).