After you click through the first two ad-cluttered pages, you start to see some results. They're presented in a single bar graph with dark shaded gradients. The graph uses the same X axis to compare three totally different quantities: CPU percentage, access time in milliseconds, and bandwidth in MB/sec. As a bonus, note that smaller values for CPU % and access time are good, but larger values of bandwidth are good. Edward Tufte, where are you?
But to harvest cane for alcohol, do you need to burn away the leaves anyway? Can't you just dump the whole plant into the fermenter? In fact, for corn sourced fermenting, do they cook the whole plant, the ears+husk, the husked corn on the cob, or just corn kernels off the cob? I remember seeing some kids show 15 years ago about a farmer making alcohol and they were using only corn kernels. Seems less efficient.
For about a year, I've been patching my Intel Compiler compiled code because of this issue. I have to give credit to a poster on the comp.arch newsgroup for an explaination of ONE of the issues, and a workaround. This is not the only anti-Athlon trick in the compiler, but it's an easy one to verify and understand.
As part of my study of Operating Systems and embedded systems, one of the things I've been looking at is compilers. I'm interested in analyzing how different compilers optimize code for different platforms.As part of this comparison, I was looking at the Intel Compiler and how itoptimizes code.The Intel Compilers have a free evaluation download from here: http://www.intel.com/products/software/index.htm?i id=Corporate+Header_prod_softwr&#compilers
One of the things that the version 8.0 of the Intel compilerincluded was an "Intel-specific" flag.According to the documentation,binaries compiled with this flag would only run on Intel processors andwould include Intel-specific optimizations to make them run faster. The documentation was unfortunatelylacking in explaining what these optimizations were, so I decided to do some investigating.
First I wanted to pick a primarily CPU-bound test to run, so I chose SPEC CPU2000.The test system was a P4 3.2G Extreme Edition with1 gig of ram running WIndows XP Pro. First I compiled and ran spec with the "generic x86 flag" (-QxW),which compiles code to run on any x86 processor.After running the generic version, I recompiled and ran spec with the "Intel-specific flag" (-QxN) to see what kind of difference that would make.For most benchmarks, there was not very much change, but for 181.mcf, there was a win of almost 22% !
Curious as to what sort of optimizations the compiler was doing to allow the Intel-specific version to run 22% faster,I tried running the same binary on my friend's computer.His computer, the second test machine, was an AMD FX51, also with 1 gig of ram, running Windows XP Pro. First I ran the "generic x86" binaries on theFX51, and then tried to run the "Intel-only" binaries. The Intel-specific ones printed out an error message saying that the processor was not supported and exited.This wasn't very helpful, was it true that only Intel processors could take advantage of this performance boost?
I started mucking around with a dissassembly of the Intel-specific binary and found one particular call (proc_init_N) that appeared to be performing this check. As far as I can tell, this call is supposed to verify that the CPU supports SSE and SSE2 and it checks the CPUID to ensure that its an Intel processor. I wrote a quick utility which I call iccOut, to go through a binary that has been compiled with this Intel-only flag and remove that check.
Once I ran the binary that was compiled with the Intel-specific flag (-QxN) through iccOut, it was able to run on the FX51. Much to my surprise, it ran fine and did not miscompare. On top of that, it got the same 22% performance boost that I saw on the Pentium4 with an actual Intel processor. This is very interesting to me, since it appears that in fact no Intel-specific optimization has been done if the AMD processor is also capable to taking advantage of these same optimizations. If I'm missing something, I'd love for someone to point it out for me. From the way it looks right now, it appears that Intel is simply "cheating" to make their processors look better against competitor's processors.
You're right that if the compiler produces code that's optimized for P4, and the different Athlon archtecture just happens not to be as efficient running that code, that'd be fair. But that's not what's happening. The Intel compiler will actually choose a slower code path for the AMD branch deliberately. It's not one set of instructions, it's two alternates. Ostensibly, the "slow" path is for compatability with old chips like the Pentium 1 and Pentium II, but the Intel compiler shuffles even the most modern Athlons into this slow path too. If you fool the compiler (or tweak the actual produced code) to make the Athlon take the "real" code path, your code runs faster.
A question I have in this (and previous more common eminent domain property takeovers for public construction) is how compensation is determined for the seized property. Is this determined by an independent third party real estate assesor? Based on the property taxes you've paid? Or just whatever the government decides to give you?
Cringely has a different style than Dvorak. Cringely is often wrong, but he admits his main point is to make people think about what could be happening, what trends may be starting. Cringely also makes predictions, but he carefully documents them, just so you CAN give him a scorecard. See his 2005 predictions: http://www.pbs.org/cringely/pulpit/pulpit20050107. html
The intertia (momentum) of the rover is effectively 0. It's moving at a speed of centimeters per day. A triple-mass rover would indeed have triple inertia, but 0*3 still equals 0.
Opportunity didn't move for two weeks because JPL is being properly conservative and haven't tried until they understood the situation. The first small movement command was given on May 14, and Opportunity moved about the way they expected.
Mr. Edison, going briefly over your new lighting method, it appears your technique requires expensive and difficult manufacturing, and a hugely expensive "electricity" plant, plus new metal cables to be run to every house, and even generating the required electricity burns more fuel than the simple candle that your new "light bulb" replaces. This would preclude lighting as one of the potential applications, which is regarded as the most promising potentials of carbon filaments. Most of the other potential applications mentioned have other well know ways of achieving that...
Its however not a lost case, Bazaar-ng is trying to fix those problems of Arch
And with the support of the community, and a lot of developer work, they'll be able to reduce Arch's 'help' text down to only 10 words, making it the most powerful source control system.
P=I^2R only for purely passively resistive circuits, where the current can be determined by voltage divided by resistance using Ohm's Law. But a CPU is a gated transistor circuit. Current is based on the number of times transistors are filled and dumped of charge, which of course is driven directly by the frequency. Voltage is fixed, so CPU wattage is pretty much linear with frequency.
Or, just brainstorming, imagine a small inductive power coil buried periodically in the street, especially at traffic lights. In the 30 seconds you're there waiting, it "tops off" your batteries. No need to go to a gas station at all! I don't know if it'd work as well on the highway, since you'd fly over a fixed coil in fractions of a second, but put them every few hundred feet, (spaced like light poles are now) and you can give every car a periodic boost. Who pays for the power is another question, but maybe not so difficult, since towns currently pay for power for streetlights, and car charging would be comparable. Electricity for vehicles is awfully cheap compared to gasoline.
The argument is that the wattage of the two compared CPUs was not identical, and therefore the results should not be compared.
Does this mean that it's "fiddling" to compare a high wattage Prescott core Pentium 4 with a lower wattage Athlon 64?
Would it be "fiddling" if you matched laptop wattage overall? (The P-M needs more support chips after all). Would it be "fiddling" if you matched chips based on equal price? Would it be "fiddling" if you matched laptops based on equal weight?
No. The comparison of the chips is fair.. AMD wasn't being deceptive about which chips they were comparing. The price, weight, frequency, cache size, wattage, and instruction set support of both chips are not secret.
The Register is just making noise to get notice and readers.
The article says they have working prototypes. Of what? The implication is that it's a device that's a square inch in size, and it holds a terabit of data. But from the usage of "square inch" I think the reality may mean a density of 1 terabit per square inch, not that they have a terabit device. (I hope I'm wrong!). For example, they may have a prototype that stores 1000 bits in an area of a billionth of a square inch. That's a lot different than an actual terabit device! I wish articles had more details...
Yamaha's CD writers burned a readable pattern into stock CDRs years ago. It was pretty readable! And the fact you didn't need special media made it practical. This was in 2002, so I can't get excited about a 2005 burner that requires special and more expensive media. You can read one review at Tom's Hardware archive. http://www6.tomshardware.com/storage/20020927/yama ha-02.html
A question.. why don't DVD players have a small memory so that when you eject a disk mid-play, they use a few bytes for the DVD's hash (to identify it) and a few bytes to remember the position where you stopped (and subtitle/audio options). Then when you pop the disk back in, it's where you left off?
I'd love this DVD player feature, and would pay for it. 16K of flash RAM to store the info for 1000 DVDs seems easy..
The answer is probably something about the DVD licenses forbidding such consumer-friendly features. The DVD consortium WANTS you to see the ads at the start of your disks! Though I'd love to know if this was indeed a legal licensing restriction.
Yes, 14 fps seems slow, doesn't it? But what are you comparing the 14 fps to? The simple stone model they show isn't an image map, it's fully procedural and not just a texture lookup.
I happen to know a bit about that specific procedural model, and on a modern CPU, I'd expect perhaps about 0.5s to render the same pixels. So that example is already an order of magnitude faster than CPU evaluations. And GPU speeds scale faster than CPU so this gulf will widen, quickly, with time.
But the poster is correct, GPU metaprogramming is NOT going to be common in games quite yet. But it's going to happen, absolutely, and the time frame is measured in just a year or two, not some vague future date. sh is fascinating because it is a solid attempt to give developers tools to start using the GPU for different kinds of computations, not just polygons/pixels/shading.
And the important applications are likely NOT to be games. Think 3D movie renderering, think fluid simulators, think finite element analysis, think fracture simulation.. all of those massively parallel, highly numeric applications. Graphics is just one of them.
The article mentions in passing one other danger.. "Team Edition". It doesnn't mention details but it clues you to the the obvious way of successfully cheating.
Imagine the advantage of having two machines side by side EACH playing a hand in the SAME game. Not only would you know more cards in play, but more importantly you could always have the ability to use the stronger hand as your main betting hand, folding the weaker hand to avoid wasting money on it. The mathematical advantage of that must be Very Large.
Seems like this cheat would be undetectable, easy to do (two internet connections so they can't compare your IP #s), and doesn't require any bot coding at all.. very adaptable to any casino or player changes or questions.
Summary: you can't trust any online betting activity.
Slashdot Mirror
After you click through the first two ad-cluttered pages, you start to see some results. They're presented in a single bar graph with dark shaded gradients.
The graph uses the same X axis to compare three totally different quantities: CPU percentage, access time in milliseconds, and bandwidth in MB/sec. As a bonus, note that smaller values for CPU % and access time are good, but larger values of bandwidth are good.
Edward Tufte, where are you?
But to harvest cane for alcohol, do you need to burn away the leaves anyway? Can't you just dump the whole plant into the fermenter?
In fact, for corn sourced fermenting, do they cook the whole plant, the ears+husk, the husked corn on the cob, or just corn kernels off the cob? I remember seeing some kids show 15 years ago about a farmer making alcohol and they were using only corn kernels. Seems less efficient.
For about a year, I've been patching my Intel Compiler compiled code because of this issue. I have to give credit to a poster on the comp.arch newsgroup for an explaination of ONE of the issues, and a workaround.
This is not the only anti-Athlon trick in the compiler, but it's an easy one to verify and understand.
From: iccOut (iccout2004@yahoo.com)
Subject: sleazy intel compiler trick (SOURCE ATTACHED)
View: Complete Thread (4 articles)
Original Format
Newsgroups: comp.arch
Date: 2004-02-09 14:38:40 PST
As part of my study of Operating Systems and embedded systems, one of
the things I've been looking at is compilers. I'm interested in
analyzing how different compilers optimize code for different
platforms.As part of this comparison, I was looking at the Intel
Compiler and how itoptimizes code.The Intel Compilers have a free
evaluation download from here:
http://www.intel.com/products/software/index.htm?i id=Corporate+Header_prod_softwr&#compilers
One of the things that the version 8.0 of the Intel compilerincluded
was an "Intel-specific" flag.According to the documentation,binaries
compiled with this flag would only run on Intel processors andwould
include Intel-specific optimizations to make them run faster. The
documentation was unfortunatelylacking in explaining what these
optimizations were, so I decided to do some investigating.
First I wanted to pick a primarily CPU-bound test to run, so I chose
SPEC CPU2000.The test system was a P4 3.2G Extreme Edition with1 gig
of ram running WIndows XP Pro. First I compiled and ran spec with the
"generic x86 flag" (-QxW),which compiles code to run on any x86
processor.After running the generic version, I recompiled and ran
spec with the "Intel-specific flag" (-QxN) to see what kind of
difference that would make.For most benchmarks, there was not very
much change, but for 181.mcf, there was a win of almost 22% !
Curious as to what sort of optimizations the compiler was doing to
allow the Intel-specific version to run 22% faster,I tried running
the same binary on my friend's computer.His computer, the second test
machine, was an AMD FX51, also with 1 gig of ram, running Windows XP
Pro. First I ran the "generic x86" binaries on theFX51, and then
tried to run the "Intel-only" binaries. The Intel-specific ones
printed out an error message saying that the processor was not
supported and exited.This wasn't very helpful, was it true that only
Intel processors could take advantage of this performance boost?
I started mucking around with a dissassembly of the Intel-specific
binary and found one particular call (proc_init_N) that appeared to be
performing this check. As far as I can tell, this call is supposed to
verify that the CPU supports SSE and SSE2 and it checks the CPUID to
ensure that its an Intel processor. I wrote a quick utility which I
call iccOut, to go through a binary that has been compiled with this
Intel-only flag and remove that check.
Once I ran the binary that was compiled with the Intel-specific flag
(-QxN) through iccOut, it was able to run on the FX51. Much to my
surprise, it ran fine and did not miscompare. On top of that, it got
the same 22% performance boost that I saw on the Pentium4 with an
actual Intel processor. This is very interesting to me, since it
appears that in fact no Intel-specific optimization has been done if
the AMD processor is also capable to taking advantage of these same
optimizations. If I'm missing something, I'd love for someone to point
it out for me. From the way it looks right now, it appears that Intel
is simply "cheating" to make their processors look better against
competitor's processors.
Links:
Intel Compiler:http://www.intel.com/products/software/in dex.htm?iid=Corporate+H
You're right that if the compiler produces code that's optimized for P4, and the different Athlon archtecture just happens not to be as efficient running that code, that'd be fair.
But that's not what's happening. The Intel compiler will actually choose a slower code path for the AMD branch deliberately. It's not one set of instructions, it's two alternates. Ostensibly, the "slow" path is for compatability with old chips like the Pentium 1 and Pentium II, but the Intel compiler shuffles even the most modern Athlons into this slow path too.
If you fool the compiler (or tweak the actual produced code) to make the Athlon take the "real" code path, your code runs faster.
A question I have in this (and previous more common eminent domain property takeovers for public construction) is how compensation is determined for the seized property. Is this determined by an independent third party real estate assesor? Based on the property taxes you've paid? Or just whatever the government decides to give you?
Cringely has a different style than Dvorak. Cringely is often wrong, but he admits his main point is to make people think about what could be happening, what trends may be starting.. html
Cringely also makes predictions, but he carefully documents them, just so you CAN give him a scorecard. See his 2005 predictions:
http://www.pbs.org/cringely/pulpit/pulpit20050107
The intertia (momentum) of the rover is effectively 0. It's moving at a speed of centimeters per day. A triple-mass rover would indeed have triple inertia, but 0*3 still equals 0.
Opportunity didn't move for two weeks because JPL is being properly conservative and haven't tried until they understood the situation. The first small movement command was given on May 14, and Opportunity moved about the way they expected.
o rtunityAll.html#sol464
http://marsrovers.jpl.nasa.gov/mission/status_opp
Mr. Edison, going briefly over your new lighting method, it appears your technique requires expensive and difficult manufacturing, and a hugely expensive "electricity" plant, plus new metal cables to be run to every house, and even generating the required electricity burns more fuel than the simple candle that your new "light bulb" replaces.
This would preclude lighting as one of the potential applications, which is regarded as the most promising potentials of carbon filaments. Most of the other potential applications mentioned have other well know ways of achieving that...
Gates never made that famous "640K is enough" quote. It's an urban legend.
m ory.html
http://tafkac.org/celebrities/bill.gates/gates_me
And with the support of the community, and a lot of developer work, they'll be able to reduce Arch's 'help' text down to only 10 words, making it the most powerful source control system.
P=I^2R only for purely passively resistive circuits, where the current can be determined by voltage divided by resistance using Ohm's Law.
But a CPU is a gated transistor circuit. Current is based on the number of times transistors are filled and dumped of charge, which of course is driven directly by the frequency. Voltage is fixed, so CPU wattage is pretty much linear with frequency.
Or, just brainstorming, imagine a small inductive power coil buried periodically in the street, especially at traffic lights. In the 30 seconds you're there waiting, it "tops off" your batteries. No need to go to a gas station at all!
I don't know if it'd work as well on the highway, since you'd fly over a fixed coil in fractions of a second, but put them every few hundred feet, (spaced like light poles are now) and you can give every car a periodic boost.
Who pays for the power is another question, but maybe not so difficult, since towns currently pay for power for streetlights, and car charging would be comparable. Electricity for vehicles is awfully cheap compared to gasoline.
The argument is that the wattage of the two compared CPUs was not identical, and therefore the results should not be compared.
Does this mean that it's "fiddling" to compare a high wattage Prescott core Pentium 4 with a lower
wattage Athlon 64?
Would it be "fiddling" if you matched laptop wattage overall? (The P-M needs more support chips after all). Would it be "fiddling" if you matched chips based on equal price? Would it be "fiddling" if you matched laptops based on equal weight?
No. The comparison of the chips is fair.. AMD wasn't being deceptive about which chips they were comparing. The price, weight, frequency, cache size, wattage, and instruction set support of both chips are not secret.
The Register is just making noise to get notice and readers.
The article says they have working prototypes. Of what? The implication is that it's a device that's a square inch in size, and it holds a terabit of data. But from the usage of "square inch" I think the reality may mean a density of 1 terabit per square inch, not that they have a terabit device. (I hope I'm wrong!). For example, they may have a prototype that stores 1000 bits in an area of a billionth of a square inch. That's a lot different than an actual terabit device! I wish articles had more details...
Yamaha's CD writers burned a readable pattern into stock CDRs years ago. It was pretty readable! And the fact you didn't need special media made it practical.a ha-02.html
This was in 2002, so I can't get excited about a 2005 burner that requires special and more expensive media.
You can read one review at Tom's Hardware archive.
http://www6.tomshardware.com/storage/20020927/yam
A question..
why don't DVD players have a small memory so that when you eject a disk mid-play, they use a few bytes for the DVD's hash (to identify it) and a few bytes to remember the position where you stopped (and subtitle/audio options). Then when you pop the disk back in, it's where you left off?
I'd love this DVD player feature, and would pay for it. 16K of flash RAM to store the info for 1000 DVDs seems easy..
The answer is probably something about the DVD licenses forbidding such consumer-friendly features. The DVD consortium WANTS you to see the ads at the start of your disks! Though I'd love to know if this was indeed a legal licensing restriction.
Actually this was kind of fun. http://www.pricewatch.com/ gives all the necessary links.
These are all-new, retail prices. Shipping + taxes not included.
CPU: 700 Mhz Celeron $18
MB: Intel 810 MB, with sound/video/USB/ethernet $10 (!)
RAM: 128MB PC2100 $15
DVD: $12
Case+300Watt PS: $24
HD: 3.5GB EIDE $17
Heatsink/Fan $1
2 IDE cables: $1
Total: $98
This even includes a DVD, not CD.
The hard drive was the surprisingly expensive part. The motherboard was the surprisingly cheap part.
Yes, 14 fps seems slow, doesn't it? But what are you comparing the 14 fps to? The simple stone model they show isn't an image map, it's fully procedural and not just a texture lookup.
I happen to know a bit about that specific procedural model, and on a modern CPU, I'd expect perhaps about 0.5s to render the same pixels.
So that example is already an order of magnitude faster than CPU evaluations. And GPU speeds scale faster than CPU so this gulf will widen, quickly, with time.
But the poster is correct, GPU metaprogramming is NOT going to be common in games quite yet. But it's going to happen, absolutely, and the time frame is measured in just a year or two, not some vague future date. sh is fascinating because it is a solid attempt to give developers tools to start using the GPU for different kinds of computations, not just polygons/pixels/shading.
And the important applications are likely NOT to be games. Think 3D movie renderering, think fluid simulators, think finite element analysis, think fracture simulation.. all of those massively parallel, highly numeric applications. Graphics is just one of them.
The article mentions in passing one other danger.. "Team Edition". It doesnn't mention details but it clues you to the the obvious way of successfully cheating.
Imagine the advantage of having two machines side by side EACH playing a hand in the SAME game. Not only would you know more cards in play, but more importantly you could always have the ability to use the stronger hand as your main betting hand, folding the weaker hand to avoid wasting money on it. The mathematical advantage of that must be Very Large.
Seems like this cheat would be undetectable, easy to do (two internet connections so they can't compare your IP #s), and doesn't require any bot coding at all.. very adaptable to any casino or player changes or questions.
Summary: you can't trust any online betting activity.