Audioslave - 7M3 - Live wrote:
Bill Nottingham wrote:
Audioslave - 7M3 - Live (creed7m3live@xxxxxxxxxxxxxxx) said:
I hope that the programs start to be compiled for at least 586 and higher applications. (maybe more efficient programs)
No. Compiling for i586 hurts you on *every* other processor variant.
I can understand all processors being able to understand the i386 instructions. I don't understand why the other variants cannot understand the i586 or newer sets.
Other Processors do not understand the newer *Intel* instructions (as Intel processors do not understand the new instructions AMD introduced). Remember that some Intel instructions *cannot* be used by other manufacturers because Intel holds patents on them!
From my short stay using the Athlon, in unfortunately, only XP. I think the athlon sets are quicker. I'd like to see how well that Linux deals with the AMD processor. Hopefully, with the new bata cycle, I can get the machine to function.
Thanks for the explaination. I should have figured out the patent limiting factors.
The other distro installed and is compiled with i586 optimization. Red Hat wouldn't even get past the disk integrity checks, on that machine.
What do you call "optimization"? -mach or -mcpu?
I was thinking in terms of the low end processor. I am getting that -mach takes into consideration the low end instructions. I am getting thst -mcpu refers to maximum machine performance, using the older instruction sets. This should probably be set to P4 classification, as suggested earlier, by another lister.
The binaries are already tuned for i686; they just don't use i686-specific instructions except in some few cases where it actually helps.
I take it that there were a lot of benchmark tests to determine that there was no substantial gains in performance. With experimenting with the kernel a bit. I did see that compiling with MMX didn't lead to any gains. It seemed, but was not timed, to be slower with that particular optimization.
The MMX instructions are only useful for certain graphics and multimedia operations (for more information see Intel's white paper), for programs which have no use for these instructions they only are additional unneeded stuff to carry along.
Carying along, I assume that this consumes memory and is not ever used for anything.
Most of the newly introduced instructions are useful only for special purposes. So in most cases it not only doesn't make any sense to use these new instructions, it is even bad! Furthermore, most of the really low-level functionality is provided by the kernel and glibc, and both are available for several processor types. Nearly all regular applications will gain *nothing* from using the new instruction sets. Red Hat does the Right Thing (TM).
Being that both are compiled by gcc, it sounds like they have to depend upon a very fine tuned compiler to benefit. If the programs put the tasks off to the kernel and the libraries, then they should be "speaking the same language". This is my thought, not based on research.
Do the processors have to shift into different modes for each set of instructions? Or are the sets of instructions accessable, equally, with all of the different built-in sets?
A processor supports certain instructions. There are no different modes. As long as the processor understands the instructions of which the binary is made of, the binary will run. If just one instruction in the binary is not understood by the processor, the binary will crash.
I was thinking that someone stated that the processor had to shift into a certain state to deal with MMX. This led me to believe that the processor had to shift into different modes for each set of instructions.
I've seen the binaries crash before. MMX arch was one time it seemed more prevailant. But in earlier days, the core dump was a very common occurence. (RHL 5.2 era)
Thanks for you ideas.
Jim
Best regards, Martin Stricker
--
Now I'm concentrating on a specific tank battle toward the end of World War II!
-- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
