jcBench Expanded Integer Results - 5/15/2012

jcBench Expanded Floating Point Results - 5/15/2012

Tonight I am hoping to add a quick comparison page so anyone could ask, well how does a Dual 600mhz Octane perform against a 600mhz O2?

Following id software's technology jumps starting with Wolfenstein 3D and hopefully one day hit Quake III level of tech.

So the initial features will be:

1. 90' Walls, Floors and Ceilings
2. Clipping
3. Texture Mapping with MIP-Mapping Support
4. OpenGL Rendering with SDL for Window Management
5. IRIX and Windows Ports

I started work on the base level editor tonight:

jcGEDitor WIP

jcBench Floating Point Performance

The biggest thing to note, is the effect Level 2 cache has on Floating Point performance.

The 4mb Level 2 cache in the R16000, clearly helps to compensate for the massive difference in clock speed. Nearly a 1 to 1 relationship between a the 6x3.2ghz Phenom II and the 4x800 MIPS R16k.

So bottom line, Level 2 cache makes up for megahertz almost by a factor of 4 in these cases. It's a shame the fastest MIPS R16000 only ran at 1ghz and is extremely rare.

More benchmarking later this week...

jcBench Integer Comparison 2

Very interesting how MIPS scales and how much of a difference 100mhz and double the Level 2 cache makes an effect on speed.

I'm still working on going back and re-running the floating point tests so that will come later today, but here are the integer performance results. Note the y-axis is the number of seconds taken to complete the test, so lower is better.

jcBench 0.2 integer comparison

Kind of a wide range of CPUs, ranging from a netbook cpu in the C-50, to a mobile cpu in the P920 to desktops cpus. The differences based on my current findings vary much more greatly with floating point operations.

A key things I got from this data:

1. Single Threaded, across the board was ridiculously slow, even with AMD's Turbo Core technology that ramps up a core or two and slows down the unused cores. Another unsettling fact for developers that continue to not write parallel programs.
2. The biggest jump was from 1 thread to 2 threads across the board
3. MIPS R14000A 600mhz CPU is slightly faster than a C-50 in both single and 2 threaded tests. Finally found a very near equal comparison, I'm wondering with the Turbo Core on the C-60 if it brings it inline.
4. numalink really does scale, even over the now not defined as "fast" numalink 3 connection, scaling it across 2 Origin 300s using all 8 cpus really did increase performance (44 seconds versus 12 seconds).

More to come later today with floating point results...

Where the TPL starts off with one thread and as it continues processing increases the threads dynamically, my implementation simply takes the number of threads specified via the command line, divides the work (in my case the number of objects) by the number of threads and kicks off the threads from the start. While TPLs implementation is great for work that you don't know if it will really even hit the maximum number of cpus/cores efficiently, for my case it actually hinders performance. I'm now wondering if you can specify from the start how many threads to kick off? If not, Microsoft, maybe add support for that? I've got a couple scenarios I know for instance would benefit from at least 4-8 threads initially, especially for data migration that I prefer to do in C# versus SSIS (call me a control freak).

Back to jcBench, at least with the current algorithm, it appears that a MIPS 600mhz R14000A with 4MB of L2 cache is roughly equivalent to a 1200mhz Phenom II with 512kb L2 cache and 6mb of L3 cache at least in Integer performance. This is based on a couple runs of the new version of jcBench. It'll be interesting to see with numalink if it continues this to 1 to 2 ratio. I'm hoping to see how different generations of AMD cpus compare to the now 10 year old MIPS cpu.

Like with many things I'm finding with Silicon Graphics machines it was pretty easy to setup. I tried to document it all below.

First off I needed to update the "rack" position of my Slave (2nd) Origin 300:

001c01-L1>brick slot 02
brick slot set to 02 (takes effect on next L1 reboot/power cycle)
001c01-L1>reboot_l1

SGI SN1 L1 Controller
Firmware Image B: Rev. 1.44.0, Built 07/17/2006 18:20:38

001c02-L1>

Next I needed to clear the serial based on the error I got:

001c02-L1>

Not able to determine correct System Serial Number
001c02 == M2002931
Please use the command 'serial clear' on the brick which
  has the serial number you do not wish to keep

Not able to determine correct System Serial Number
001c16 == M2100250
Please use the command 'serial clear' on the brick which
  has the serial number you do not wish to keep

001c02-L1>serial clear

Unplugged the power to both and then hooked them up with the numalink cable:

Silicon Graphics Origin 300s connected via numalink

Then plugged both power cables back in and hit power button on both. To my surprise upon starting up IRIX everything worked.

[SPEEDO2]:~ $ hinv -vm
Location: /hw/module/001c01/node
       IP45_4CPU Board: barcode MNS886     part 030-1797-001 rev -B
Location: /hw/module/001c01/Ibrick/xtalk/14
             IO8 Board: barcode MJX813     part 030-1673-003 rev -F
Location: /hw/module/001c01/Ibrick/xtalk/15
             IO8 Board: barcode MJX813     part 030-1673-003 rev -F
Location: /hw/module/001c02/node
       IP45_4CPU Board: barcode MNM964     part 030-1797-001 rev -B
Location: /hw/module/001c02/Ibrick/xtalk/14
             IO8 Board: barcode MHE546     part 030-1673-003 rev -E
Location: /hw/module/001c02/Ibrick/xtalk/15
             IO8 Board: barcode MHE546     part 030-1673-003 rev -E
8 600 MHZ IP35 Processors
CPU: MIPS R14000 Processor Chip Revision: 2.4
FPU: MIPS R14010 Floating Point Chip Revision: 2.4
CPU 0 at Module 001c01/Slot 0/Slice A: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0x1a
CPU 1 at Module 001c01/Slot 0/Slice B: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0x1a
CPU 2 at Module 001c01/Slot 0/Slice C: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0x1a
CPU 3 at Module 001c01/Slot 0/Slice D: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0x1a
CPU 4 at Module 001c02/Slot 0/Slice A: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0xa
CPU 5 at Module 001c02/Slot 0/Slice B: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0xa
CPU 6 at Module 001c02/Slot 0/Slice C: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0xa
CPU 7 at Module 001c02/Slot 0/Slice D: 600 Mhz MIPS R14000 Processor Chip (enabled)
  Processor revision: 2.4. Scache: Size 4 MB Speed 300 Mhz  Tap 0xa
Main memory size: 8192 Mbytes
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 4 Mbytes
Memory at Module 001c01/Slot 0: 4096 MB (enabled)
  Bank 0 contains 1024 MB (Premium) DIMMS (enabled)
  Bank 1 contains 1024 MB (Premium) DIMMS (enabled)
  Bank 2 contains 1024 MB (Premium) DIMMS (enabled)
  Bank 3 contains 1024 MB (Premium) DIMMS (enabled)
Memory at Module 001c02/Slot 0: 4096 MB (enabled)
  Bank 0 contains 1024 MB (Premium) DIMMS (enabled)
  Bank 1 contains 1024 MB (Premium) DIMMS (enabled)
  Bank 2 contains 1024 MB (Premium) DIMMS (enabled)
  Bank 3 contains 1024 MB (Premium) DIMMS (enabled)
Integral SCSI controller 8: Version Fibre Channel LS949X Port 0
Integral SCSI controller 9: Version Fibre Channel LS949X Port 1
Integral SCSI controller 10: Version QL12160, low voltage differential
Integral SCSI controller 11: Version QL12160, low voltage differential
Integral SCSI controller 0: Version QL12160, low voltage differential
  Disk drive: unit 1 on SCSI controller 0 (unit 1)
Integral SCSI controller 1: Version QL12160, low voltage differential
Integral SCSI controller 12: Version QL12160, low voltage differential
Integral SCSI controller 13: Version QL12160, low voltage differential
IOC3/IOC4 serial port: tty5
IOC3/IOC4 serial port: tty6
IOC3/IOC4 serial port: tty7
IOC3/IOC4 serial port: tty8
Gigabit Ethernet: eg1, module 001c01, pci_bus 2, pci_slot 2, firmware version 0.0.0
Gigabit Ethernet: eg2, module 001c02, pci_bus 2, pci_slot 1, firmware version 0.0.0
Integral Fast Ethernet: ef0, version 1, module 001c01, pci 4
Fast Ethernet: ef1, version 1, module 001c02, pci 4
  PCI Adapter ID (vendor 0x1000, device 0x0640) PCI slot 1
  PCI Adapter ID (vendor 0x1000, device 0x0640) PCI slot 1
  PCI Adapter ID (vendor 0x10a9, device 0x0009) PCI slot 2
  PCI Adapter ID (vendor 0x10a9, device 0x0009) PCI slot 1
  PCI Adapter ID (vendor 0x1077, device 0x1216) PCI slot 2
  PCI Adapter ID (vendor 0x1077, device 0x1216) PCI slot 1
  PCI Adapter ID (vendor 0x10a9, device 0x0003) PCI slot 4
  PCI Adapter ID (vendor 0x11c1, device 0x5802) PCI slot 5
  PCI Adapter ID (vendor 0x1077, device 0x1216) PCI slot 1
  PCI Adapter ID (vendor 0x10a9, device 0x0003) PCI slot 4
  PCI Adapter ID (vendor 0x11c1, device 0x5802) PCI slot 5
IOC3/IOC4 external interrupts: 1
IOC3/IOC4 external interrupts: 2
HUB in Module 001c01/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
HUB in Module 001c02/Slot 0: Revision 2 Speed 200.00 Mhz (enabled)
IP35prom in Module 001c01/Slot n0: Revision 6.124
IP35prom in Module 001c02/Slot n0: Revision 6.210
USB controller: type OHCI
USB controller: type OHCI

You've probably done something like this in your code since your C or C++ days:

string tmpStr = String.Empty;

foreach (contact c in contacts) {
    tmpStr += c.FirstName + " " + c.LastName + ",";
}

return tmpStr;

And most likely doing some manipulation otherwise it would probably make more sense to simply concatenate the string in your SQL Query itself.

After thinking about it some more, I considered the following code instead:

return string.Join(",", contacts.Select(a => a.FirstName + " " + a.LastName));

Simple, clean and faster?

On 10,000 Contact Entity Objects (averaged against 3 test runs):
Traditional Method - 1.4050804 seconds
Newer Method - 0.0270016 seconds

About 50 times faster to do the newer method, what about with an even larger dataset of 100,000?
Traditional Method - 151.0996424 seconds
Newer Method - 0.09200503 seconds

Nearly 1700 times faster to do the newer method, but now what about a smaller set of 1000?
Traditional Method - 0.0410024 seconds
Newer Method - 0.0160009 seconds

About 2 times faster.

In visual terms:

Traditional vs Newer Method Test Results

This is far from a conclusive, in-depth test. But for larger data sets or in a high traffic/high demand (like a WCF Call that returns a delineated String for instance), string.Join should be used instead. That being said though, the data should be formatted properly ahead of time and any possible error (null values etc) should be considered a precondition to using string.Join.

For me, it really got my mind thinking about other small blocks of code that I had been stagnantly using over the years that could speed up intensive tasks, especially with the size of a lot of the results I parse through at work.

My 2nd Silicon Graphics Origin 300

Original Silicon Graphics Origin 300 Fans out...

Quad R14k 500 Swap completed

Silicon Graphics Origin 300 1GB DDR Stick

Off the bat I was presented with:

Silicon Graphics Origin 300 L1 - Unknown Brick Type!

Upon hooking up my USB->Null Modem cable I checked the L1 Log:

001?01-L1>log
04/14/12 10:54:46 L1 booting 1.44.0
04/14/12 10:54:49 ** fixing invalid SSN value
04/14/12 10:54:49 ** fixing BSN mismatch
04/14/12 11:13:53 L1 booting 1.44.0


So, good it auto-fixed the invalid SSN and BSN mismatch.

001?01-L1>brick
rack: 001, slot: 01, partition: none, type: Unknown [2MB flash], serial:MRH006, source: NVRAM


Good again, it sees the brick, but doesn't know what it is.

Then tried:

001?01-L1>brick type C
brick type changed (nvram) (takes effect on next L1 reboot/power cycle)
001?01-L1>reboot_l1


Upon rebooting the L1, still not avail. Going to have to get creative with this problem...

Scored an official Silicon Graphics Gigabit card off eBay for next to nothing, installed it with no problems and upon rebooting IRIX recognized it and am now only using the gigabit connection to the rest of my network.

Silicon Graphics Gigabit PCI-X Card

Next up was another great find on eBay for ~$30 I got a Dual Channel 4gb LSI Logic PCI-X card that has built in IRIX support. Just waiting on a PCI Express 4gb card to put into my SAN.

LSI Dual Channel 4gb Fibre Channel

SGI Gigabit and LSI Logic Dual Channel 4gb Fibre PCI-X cards installed