Wednesday,
october 29:
I downloaded two different executable code profilers to test my assertion that in normal use, floating point instructions are rarely if ever executed. The first one was written by Stephan Meyer, the second one by Cuneyt Akinlar.
Both profilers make use of the special Model Specific Registers found in the Pentium and 6x86MX CPUs (missing on the 6x86 and 6x86L, though; I think the K6 has them), which allow counting the occurrences of specific events in the execution flow. One of these events is the execution of floating point instructions.
I am working on a new release of Cuneyt's profiler, which I will place under GPL (as authorized by Cuneyt). This profiler package takes the form of a simple driver module that can be loaded and unloaded at will, and an associated library which you can link with any program that you would like to test. You will soon find the new driver and library on these pages for download.
Meanwhile, I can confirm what we already knew: the Linux kernel does not make use of any floating-point instructions, and unless you are using the GIMP for special image manipulations, or executing some heavy duty scientific application, the FPU of your 6x86 is not used. More numbers Real Soon Now.
Sunday,
october 26:
I have finally setup a Guestbook for these pages. I would appreciate having your feedback, and it will help whenever I want to ask Cyrix and IBM specific technical questions. GNU/Linux users rarely get the recognition they deserve as "power users" from the microcomputer industry.
Plus, of course, it motivates me to write new and better pages.
Saturday,
october 25:
Remember that IBM 6x86MX Rev. 1.3 rated @ 133 MHz (2 x 66) I received three weeks ago? I had already overclocked it to 150 MHz (2 x 75) on my ASUS P55T2P4 Rev. 3.10 motherboard, without any problems. I just thought I would go one step further and overclocked it first to 166 MHz @ 2.5 x 66, and then to 166 MHz @ 2 x 83, again without any hitches and without raising the core voltage beyond its nominal 2.9V setting. I tried some higher clock rates, but without success.
Here are some Linux 2.0.0 kernel compilation times for you to chew on:
|
Processor |
Clock |
Multiplier |
Kernel compilation in |
|
6x86L |
150 MHz |
(2 x 75) |
6 min 43 sec |
|
6x86MX |
150 MHz |
(2 x 75) |
5 min 03 sec |
|
6x86MX |
166 MHz |
(2.5 x 66) |
4 min 30 sec |
|
6x86MX |
166 MHz |
(2 x 83) |
4 min 20 sec |
The same GNU/Linux box was used for all these tests: ASUS HX-based motherboard, with 512Kb cache, 32Mb 60ns EDO DRAM, IBM EIDE DMA mode 2 bus mastering 4.3Gb hard disk. Also, Andy Kahn has kindly sent me the following result for his K6-233 GNU/Linux box:
|
Processor |
Clock |
Multiplier |
Kernel compilation in |
|
AMD K6 |
233 MHz |
(3.5 x 66) |
3 min 37 sec |
Andy is using an ASUS TX-97X motherboard with 512Kb cache and 32Mb 10ns SDRAM, and has the latest Maxtor 6.3Gb EIDE hard disk drive. I am very impressed with these figures. If you want to try this benchmark and send me your results (for any processor), please first take a look at the latest version of my Linux Benchmarking HOWTO. You'll have to fill a simple Benchmark Report Form.
From the above benchmark results, it appears that Linux 2.0.0 kernel compilation time basically depends on CPU/Memory bandwidth, and in this respect cache size + architecture and DRAM type play a fundamental role. The hard disk subsystem does not seem to be a bottleneck for kernel compilation, at least for modern EIDE drives.
A different motherboard with 10ns SDRAM would have to be tested to determine to what degree the lower clock rates of the 6x86MX can be compensated by its advanced architecture, when compared to the K6. It seems (by extrapolating from the above results) that a 6x86MX @ 200 MHz would almost match a K6-233 on the kernel compilation benchmark, given or taken a few seconds. This is quite an achievement, considering that the 6x86MX has "only" 6.3 million transistors versus the K6 8.8 million; note that the 64Kb L1 cache that both chips feature uses approximately 3.5 million transistors, so the K6 CPU itself with nearly twice the transistor count of the 6x86MX is considerably more complex.
I didn't even mention Intel's Pentium chips up to now. I am late in delivering my Intel Pentium benchmarks, these should be done Real Soon Now, but don't expect a fifth-generation Pentium chip to perform nearly as well at comparable clock rates as a K6 or a 6x86MX. For a fair comparison with the K6 and 6x86MX, somebody would have to send me results for a P55C or a Pentium II @ 233 MHz (these chips are beyond my actual financial means).
Friday,
october 24:
GNU/Linux Cyrix P200+ CPUs can be clustered to perform large database searches at speeds comparable to supercomputers (at 1/20th the cost). An interesting description of the actual setup of such a system built in Lausanne, Switzerland for biocomputing research, can be found here.
I have added a GIF image of switching voltage regulator coils to the FAQ page.
I am also trying to change all references to the Linux operating system in my pages to "GNU/Linux", since "Linux" alone is correct only as far as the Linux kernel is concerned.
Monday,
october 20:
As suggested by Greg Smith, I have updated the Motherboards page to include information on the popular M-Tech Mustang R534 motherboard (SiS 5571B chipset based).
Thursday,
october 16:
Cyrix gave us a glimpse of what their new processor, code named MXi, will look like: a new dual-issue fully pipelined FPU translating into 1 GFLOPS peak performance and single-cycle throughput on standard x86 floating-point instructions, 2Gb/s CPU to memory bandwidth, an improved integer unit, the same 64Kb cache as the 6x86MX, all that crammed into a 90mm² die (0.25 micron, 5 layer technology). PR ratings (I wish Cyrix would drop this senseless rating system someday) will range from PR300 to PR400. Production Q4 1998. Since the die is rather small, this processor will likely be affordable. But Cyrix didn't say whether the MXi would fit a Socket 7 motherboard.
Wednesday,
october 15:
It seems the new Intel Merced CPU (Intel's first implementation of its new IA64 architecture), to be released in 1999, will need a very special compiler design to handle its unique 128-bit instruction "bundles", which are needed to obtain speculative execution performance gains. Interestingly, the Cyrix 6x86 obtains such gains through neat design features, while maintaining x86 compatibility, and without any special compiler optimization whatsoever.
My feeling is we won't be seeing GNU/Linux on a Merced chip for quite some time, which is perhaps exactly what Wintel wants...
Sunday,
october 12:
I have added a new page on the 6x86MX. I have just confirmed that the 6x86MX I received a week ago is a Rev. 1.3 chip. Its DIR1 value is 03h.
I also added a link on the main page to a work-in-progress VSPM explanation I am putting together (just click on the small "Under Construction" icon).
Thursday,
october 9:
A short article in PC Week by Lisa DiCarlo mentions release dates and PR ratings for future 6x86MX CPUs. In the article clock speeds (in MHz) are mentionned, but this is probably a misunderstanding, the figures DiCarlo got from Cyrix are probably PR ratings. The real clock rates below are my guesses.
Improved 0.35 micron dies:
New 0.25 micron process:
If Cyrix manages to stick to this time schedule or something similar, we shall not need to throw out our old Socket 7 motherboards and rush out to buy the Intel-proprietary Slot-1 and Slot-2 motherboards and CPUs. Since Cyrix is now backed by a highly profitable and very stable company like National Semiconductor, it seems they have good chances of staying in the high-performance CPU business.
Meanwhile, Intel is buying out Digital's Alpha 64-bit CPU in a legal battle settlement with Digital Semiconductors... because another Digital division needs Intel chips for its line of x86 Windows NT workstations!
What does all this mean for GNU/Linux users? As a GNU/Linux user, I don't want to be forced to buy a particular brand of CPU two years from now, just to get decent performance. The $10K+ SPARC workstations are not an alternative to x86 CPUs, IMHO; also you can't mail order a new SPARC motherboard and stick it in your good old mini-tower case.
In fact, on sub-$1000 boxes, GNU/Linux makes much more sense than other OS's priced higher than $100, from a marketing point of view, because the margins in this market segment are very low. And these sub-$1000 boxes in August 1997 have begun to represent 40% of total microcomputer sales!
Sunday,
october 5:
The IBM 6x86MX labeled 2 x 66 MHz overclocked quite easily to 2 x 75 MHz on my ASUS P55T2P4 Rev. 3.1 Intel 430HX based motherboard. As far as GNU/Linux performance (see the Linux Benchmarking Project pages) and transistor count (> 6 million) are concerned, this CPU is a bargain.
Saturday,
october 4:
I just received an IBM 6x86MX marked as follows:
|
IBM26x86MX-AVAPR166GA 2.0x 66MHZ-2.9V CORE |
which I assume is a Rev. 1.3 6x86MX. Notice the space between the 2.0x and the 66MHZ markings? The PR233 version of the 6x86MX is available as a 2 x 83 MHz part, so can we assume a 100+ MHz host bus clock part is on the way?
I will be doing some comparative GNU/Linux benchmarking of the 6x86MX against an Intel Pentium 133 and also against my old 6x86L. All chips will be running at 133 MHz core clock, 2 x 66 MHz host bus speed. I know this is totally unfair to the Intel part which is a previous generation chip, but I want to determine how efficient each CPU architecture is under GNU/Linux (see the latest version of my Linux Benchmarking HOWTO for benchmarking guidelines on GNU/Linux systems), at the same core clock and host bus speed.
I also want to determine the % of FPU instructions in the execution flow of the average GNU/Linux box, using the event counters in the 6x86MX chip. My guess is that FPU opcodes represent a very low percentage of the total instructions executed, and so the traditional argument that compares 6x86 CPUs to their Intel Pentium counterparts, attributing a significant weight to FPU performance (where the 6x86 is up to 50% slower than an Intel Pentium) is not justified and in fact constitutes a methodological mistake if used for benchmarking purposes.
Last updated on October 29, 1997.
Copyright 1997 Andrew D. Balsa