AMD64 Opteron: First Look
Because this is a new fast system, after typing uname -a at the bash prompt, the next thing you do is cat /proc/cpuinfo:
processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron™ stepping : 0 cpu MHz : 1594.286 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips : 3178.49 TLB size : 1088 4K pages clflush size : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts ttp
Processor 1's information is the same but with a BogoMips of 3185.04.
The main GUI environment supported on SuSE Linux Enterprise Server 8 is KDE 3.0, and the system comes with all the regular tools and applications usually expected with a SuSE distribution. The SuSE Enterprise Linux implementation on the Opteron itself is the result of a lot of hard work and a long history of 64-bit Linux hacking, dating back to when Jon “maddog” Hall first gave Linus Torvalds a Digital Alpha.
The GNU environment simply works—only at 64 bits. All of the usual compilers and the GNU build environment work right out of the box. One of the first things you notice with this system is that Emacs starts immediately, faster than you can blink.
The first test was to compile and run the GNU Scientific Library (GSL), which is a numerical computing library. This library itself is rather robust, and we compiled version 1.3. Then we compiled some sample code from the GNU Scientific Library Reference Manual to generate random numbers. This really simple program, which was compiled without any optimization, revealed that this system was about three times faster than the same program on x86 at 800MHz.
However, we learned right away how often programming is done with the unconscious thought that it's a 32-bit system. One part of the test program left-shifted an integer 1 by sizeof(int) * 8 - 1 to obtain the number of bits, based on the bit size of the machine's native integer. On this machine, in contrast to typical x86 PCs, compiling the program with that nonportable hack caused immediate integer overflow. Although common tools are now 64-bit clean, your locally developed code may need some work.
We performed the next test with the Icarus Verilog compiler. Icarus Verilog is a GPLed Verilog HDL compiler for electronic design automation (EDA), especially HDL simulation and synthesis. Linux Journal has interviewed Stephen Williams, the author of Icarus, two times now [see “Open Source in Electronic Design Automation”, LJ, February 2001, www.linuxjournal.com/article/4428 and “A Conversation with Stephen Williams”, LJ, July 2002, www.linuxjournal.com/article/6002]. Over time, we have documented the steadily increasing advances this compiler has made as a serious industrial-strength EDA tool for logic and FPGA design. Because Stephen has been building Icarus as 64-bit clean code for the past five years under Linux for Alpha, compiling the compiler was relatively easy. What was of interest was learning how fast it was and how well it responded to large workloads and many more cycles of operation in terms of runtime.
We tested a large multiplier logic model and testbench from the Icarus test suite, and it was almost twice as fast as a 1.5GHz Athlon processor running the same binary. For the large workload test, we compiled a logic model consisting of 1,720,648 lines of Verilog code. This also was breathtaking. In 61 minutes, the machine compiled a model with a memory footprint larger than the largest user space in 32-bit Linux—3.6GB.
Because Icarus uses its own internal threading system, these particular EDA tests used only one-half of this computer. Another processor, with scalable memory bandwidth, runs more EDA simulation projects without even affecting the first. Opteron clearly is well suited as server technology for engineering work.
The last major test compiled was for the Linux Test Project (LTP). The LTP is a GPLed test environment for Linux, available for download on SourceForge (see Resources). The version tested was ltp-full-20030404, which is from early April 2003. It compiled and ran the default tests with no problem whatsoever.
A qualitative summary of the LTP tests would be that 64-bit SuSE Enterprise Linux is squeaky clean—numerous picayune Linux system calls are tested in LTP. There were extremely few failures, and of these, none were of any substantive impact. In our experience, this same LTP on some other recent 32-bit Linux distributions has many more test fails, including actual crashes.
Although the LTP is well geared for testing Linux, some other more quantitative data about the Opteron is necessary to begin to glean numerically the limits to performance for this processor and system architecture. We turn now to some preliminary benchmarks.
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development