No... but why not do a fair comparison and make all else equal but the CPU? Otherwise, let's put together the crappiest Intel system we can together, and put the crappiest AMD one together... wait... there is only one such AMD system so it is both the crappiest and best by definition... and then let's compare them!
Since there is exactly one such AMD system in existance, do you think it *might have possibly* been made with an integrated graphics solution that is better than the competition in order for benchmarks to be favorable? The Intel integrated graphics are practically ancient. The ATi is realtively new (compared to the Intel in any case). It's pretty easy to find benchmarks for the Intel and then find an ATi that will beat it to make your *reference* platform for benchmarking beat the Intel.
I got a good idea... let's race cars, but I get to buy my car after I find out what kind of car you will be bringing to the race.
You realise Intel MANDATES that every Centrino using integrated graphics must use Intel integrated graphics, right? You realise that Intel has discouraged ATI and others from producing top-of-the-line integrated video chipsets for Pentium M because they are not allowed in Centrino bundles, right?
Oddly enough, my officially branded Centrino laptop has nVidia's Go5650 graphics in it. Newer models of my laptop have ATi's Mobility 9600 in them and they also retain the official Centrino label. They aren't "integrated" as in the chipset, but my Go5650 is the only GPU in my laptop as far as I can see (no drivers for any other graphics are loaded and there's no listing of hardware that doesn't have a driver for it).
That may sound "rational" but in 64-bit mode you get more registers and the core is more efficient [hint: think more idle time]. So in reality you spend less time doing regular stuff such as handling interupts, handling a filesystem, decoding network packets, etc...
You're also flipping more bits every time you manipulate an address, for instance. Most of the time (excluding file system manipulation), there should be little difference between 32-bit and 64-bit mode in the situations you've described. 64-bit mode will probably use a minute bit more of power than 32-bit mode, but probably not enough to really worry about... so you get 2:30 minutes of battery life in 64-bit mode but 2:32 minutes in 32-bit mode type thing (just making those numbers up to demonstrate a small difference in the two).
Transistors switching uses power. In 64-bit mode, all addresses are 64-bit internally (although fewer bits are brought to the outside world). 64-bit addresses require 64-bit arithmetic operations. 32-bit require 32-bit operations. 64-bit ALU operations require more bits to flip than 32-bit ones.
That being said, I think that the difference in power consumption would be pretty small, but technically, I'm pretty sure it would use more power (even if it was like 0.1W over the course of an hour).
How can they tell that a binary has GPL code in it? I mean, do they use strings or something? If that's it, then it's pretty easy to defeat their GPL detection. Looking at the assembly isn't telling because some simple algorithms will be written the same and produce similar assembly, and optimizations will mangle all that anyway.
Strange... MSVC and Intel's compiler are usually the top and gcc is lower, for me. Most benchmarks I've seen on the web follow my experiences as well...
The word "thread" is fine. If a thread is blocked, on IO for example, another thread that is "ready to run" from the same, or any other, process can be scheduled. Most thread aware OSs schedule threads as their base unit of execution. Of course, there are some advantages with scheduling threads from the same process over those from another process, but the base premise is OK for discussion.
Cool, we did a bunch of research back in the mid 90s using MPI and published some papers about threaded communications and the like inside of MPI implementations. Also, it was common practice back on the i860 paragons with two or three processors per node to devote one of the CPUs totally to communications while the other cranked away.
Also, be careful that you take the working set into consideration. Suppose you had one processor with 1M L2 cache but your problem needed 1.5M data to work on. It runs at around main memory speeds. However, take two such processors and (if you can) divide the data in half, each processor can now fit all of its data inside L2, which runs at L2 speeds. You can see superlinear speedups that way too.
However, what you are saying is pretty much right on... communication overhead is almost all integer work so if you have an FPU compute thread going on and have the communications offloaded to a thread, those two things should play quite nicely on hyperthreaded Intel parts. This is even cheaper than the other past solutions of burning an entire CPU for communications while the other does computation.
That's fine for producer/consumer type problems, but there are other types of problems that don't lend themselves to that model.
I've been programming multithreaded code for a while, too, and giant locking (which is what you describe) is not very efficient much of the time for what I've done in the past. Linux and Solaris had this type of architecture for the kernel at one time and they've long since evolved away from that.
In short, how you use threads really depends on what you are trying to do. Hammering all multi-threaded programming into this one model may not be efficient or easy. That model does serve nicely for a number of tasks, but not all.
WTH are you smoking? Dual core processors have nothing to do with that mock up Mini box thing.
Intel and AMD both have demonstrated dual core processors recently and even Dell gave away some dual core workstations as door prizes recently. Dual core Intel boxes are supposed to be fully in the channel a month from now and AMD isn't far behind, if any.
Conversely, if you have in-house programmers and you plan to use the software a while, it may be very much worth your while to have someone in-house familiar with the software so that any more changes beyond that first are easier. You can pay the original author a bunch of money a few times, or you can just use your in-house labor to do it cheaper over time/feature added. If you only have one feature, it may be cheaper, but if you have a few features or a fair amount of just 'tuning' or other changes, it'll more likely be cheaper for in-house programmers to do it. This is especially true if you need the software to integrate or interface with existing systems in-house. Such existing systems may be hardware and, even more likely and probably very common, in-house databases that the original author won't have access to.
On-going maintenance is iffy... if what you have in-house is working fine, there's no reason to upgrade to a new major release, especially since you may now have a vested interest in the in-house code you have now.
I guess 'find' will show you file names (but not contents) of files you don't have access to. However, as any-old-user, I do get plenty of 'permission denied' messages when doing a 'find' from '/'. Can you also do something like: 'find . -type f -name somefilename -exec somescript {} \;' using slocate?
Of course, if said company already has programmers, they'll just download the source and do it themselves after studying the code for a while... unless you also recommend writing code that isn't understandable...
Your model mostly assumes mom-n-pop type shops, who also usually have small amounts of money to pay for such things and will balk at 4-figure costs (and especially 5-figure costs) to do these things.
So.... he didn't really "switch". He just was given new hardware at work, he put Linux on it, and is using it. Sounds like much ado over nothing, to me.
Usually as soon as I see someone saying "All of the enemies! Everywhere! They're out to get us!" I start looking for a tinfoil hat.... Have they gone over the deep end?
But that's not what he said... He said he compiled it on Fedora 2, then copied the binary to Fedora 3 and the result when running it was a segmentation fault.
What you should have said was that you compiled something on Win98/ME and it didn't run on Windows XP (which probably would have been false anyway).
Slashdot Mirror
No... but why not do a fair comparison and make all else equal but the CPU? Otherwise, let's put together the crappiest Intel system we can together, and put the crappiest AMD one together... wait... there is only one such AMD system so it is both the crappiest and best by definition... and then let's compare them!
Since there is exactly one such AMD system in existance, do you think it *might have possibly* been made with an integrated graphics solution that is better than the competition in order for benchmarks to be favorable? The Intel integrated graphics are practically ancient. The ATi is realtively new (compared to the Intel in any case). It's pretty easy to find benchmarks for the Intel and then find an ATi that will beat it to make your *reference* platform for benchmarking beat the Intel.
I got a good idea... let's race cars, but I get to buy my car after I find out what kind of car you will be bringing to the race.
You realise Intel MANDATES that every Centrino using integrated graphics must use Intel integrated graphics, right? You realise that Intel has discouraged ATI and others from producing top-of-the-line integrated video chipsets for Pentium M because they are not allowed in Centrino bundles, right?
Oddly enough, my officially branded Centrino laptop has nVidia's Go5650 graphics in it. Newer models of my laptop have ATi's Mobility 9600 in them and they also retain the official Centrino label. They aren't "integrated" as in the chipset, but my Go5650 is the only GPU in my laptop as far as I can see (no drivers for any other graphics are loaded and there's no listing of hardware that doesn't have a driver for it).
That may sound "rational" but in 64-bit mode you get more registers and the core is more efficient [hint: think more idle time]. So in reality you spend less time doing regular stuff such as handling interupts, handling a filesystem, decoding network packets, etc...
You're also flipping more bits every time you manipulate an address, for instance. Most of the time (excluding file system manipulation), there should be little difference between 32-bit and 64-bit mode in the situations you've described. 64-bit mode will probably use a minute bit more of power than 32-bit mode, but probably not enough to really worry about... so you get 2:30 minutes of battery life in 64-bit mode but 2:32 minutes in 32-bit mode type thing (just making those numbers up to demonstrate a small difference in the two).
Transistors switching uses power. In 64-bit mode, all addresses are 64-bit internally (although fewer bits are brought to the outside world). 64-bit addresses require 64-bit arithmetic operations. 32-bit require 32-bit operations. 64-bit ALU operations require more bits to flip than 32-bit ones.
That being said, I think that the difference in power consumption would be pretty small, but technically, I'm pretty sure it would use more power (even if it was like 0.1W over the course of an hour).
I've watched two DVD movies back to back on my Pentium-M laptop while in an airport waiting on a flight (that was running late).
What happens if you write code that just works? :)
The Riverdance Director's edition?
How can they tell that a binary has GPL code in it? I mean, do they use strings or something? If that's it, then it's pretty easy to defeat their GPL detection. Looking at the assembly isn't telling because some simple algorithms will be written the same and produce similar assembly, and optimizations will mangle all that anyway.
Strange... MSVC and Intel's compiler are usually the top and gcc is lower, for me. Most benchmarks I've seen on the web follow my experiences as well...
What about valgrind? (I guess mudflap will work everywhere and valgrind is x86 is the advantage.) I use valgrind all the time, it's a great tool.
The word "thread" is fine. If a thread is blocked, on IO for example, another thread that is "ready to run" from the same, or any other, process can be scheduled. Most thread aware OSs schedule threads as their base unit of execution. Of course, there are some advantages with scheduling threads from the same process over those from another process, but the base premise is OK for discussion.
Cool, we did a bunch of research back in the mid 90s using MPI and published some papers about threaded communications and the like inside of MPI implementations. Also, it was common practice back on the i860 paragons with two or three processors per node to devote one of the CPUs totally to communications while the other cranked away.
Also, be careful that you take the working set into consideration. Suppose you had one processor with 1M L2 cache but your problem needed 1.5M data to work on. It runs at around main memory speeds. However, take two such processors and (if you can) divide the data in half, each processor can now fit all of its data inside L2, which runs at L2 speeds. You can see superlinear speedups that way too.
However, what you are saying is pretty much right on... communication overhead is almost all integer work so if you have an FPU compute thread going on and have the communications offloaded to a thread, those two things should play quite nicely on hyperthreaded Intel parts. This is even cheaper than the other past solutions of burning an entire CPU for communications while the other does computation.
That's fine for producer/consumer type problems, but there are other types of problems that don't lend themselves to that model.
I've been programming multithreaded code for a while, too, and giant locking (which is what you describe) is not very efficient much of the time for what I've done in the past. Linux and Solaris had this type of architecture for the kernel at one time and they've long since evolved away from that.
In short, how you use threads really depends on what you are trying to do. Hammering all multi-threaded programming into this one model may not be efficient or easy. That model does serve nicely for a number of tasks, but not all.
WTH are you smoking? Dual core processors have nothing to do with that mock up Mini box thing.
Intel and AMD both have demonstrated dual core processors recently and even Dell gave away some dual core workstations as door prizes recently. Dual core Intel boxes are supposed to be fully in the channel a month from now and AMD isn't far behind, if any.
Conversely, if you have in-house programmers and you plan to use the software a while, it may be very much worth your while to have someone in-house familiar with the software so that any more changes beyond that first are easier. You can pay the original author a bunch of money a few times, or you can just use your in-house labor to do it cheaper over time/feature added. If you only have one feature, it may be cheaper, but if you have a few features or a fair amount of just 'tuning' or other changes, it'll more likely be cheaper for in-house programmers to do it. This is especially true if you need the software to integrate or interface with existing systems in-house. Such existing systems may be hardware and, even more likely and probably very common, in-house databases that the original author won't have access to.
On-going maintenance is iffy... if what you have in-house is working fine, there's no reason to upgrade to a new major release, especially since you may now have a vested interest in the in-house code you have now.
I guess 'find' will show you file names (but not contents) of files you don't have access to. However, as any-old-user, I do get plenty of 'permission denied' messages when doing a 'find' from '/'. Can you also do something like: 'find . -type f -name somefilename -exec somescript {} \;' using slocate?
Of course, if said company already has programmers, they'll just download the source and do it themselves after studying the code for a while... unless you also recommend writing code that isn't understandable...
Your model mostly assumes mom-n-pop type shops, who also usually have small amounts of money to pay for such things and will balk at 4-figure costs (and especially 5-figure costs) to do these things.
So.... he didn't really "switch". He just was given new hardware at work, he put Linux on it, and is using it. Sounds like much ado over nothing, to me.
How about just oldskool 'find'?
Usually as soon as I see someone saying "All of the enemies! Everywhere! They're out to get us!" I start looking for a tinfoil hat.... Have they gone over the deep end?
Dunno... you'll have to try it to see. Compiling static isn't a silver bullet.
Don't accidently drop it and try to catch it! It'll cut off your fingers! (as seen in sci-fi shows... the molecular blade)
Anybody out there know anyone doing a port of MegaWars III (from CompuServe days)?
HOLY CRAP! I was just talking about Carrier Command to a friend at lunch. I, too, loved playing it on my AtariST. I will bookmark that site... thanks!
But that's not what he said... He said he compiled it on Fedora 2, then copied the binary to Fedora 3 and the result when running it was a segmentation fault.
What you should have said was that you compiled something on Win98/ME and it didn't run on Windows XP (which probably would have been false anyway).