Programming

Ramen_noodle and migurus, can you please post the result of the following command here:

Code:

 grep -E "(model|cpu|flags)" /proc/cpuinfo  |sort -u

Thank you kindly. I'm especially interested in the "flags".

Code:

cpu cores       : 2
cpu family      : 6
cpuid level     : 10
cpu MHz         : 1200.000
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
model           : 15
model name      : Intel(R) Core(TM)2 CPU          4300  @ 1.80GHz

cpu family : 15
cpuid level : 5
cpu MHz : 3201.990
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm pni monitor ds_cpl cid xtpr
model : 4
model name : Intel(R) Xeon(TM) CPU 3.20GHz

Thanks Migurus. So "sep" is not implemented on your XEON, confirming that the syscall/sysent thingy is a red herring.

I have run benchmarks on the following hardware: These systems were under various amounts of load, so averages were taken, and they cannot be deemed 100% reliable. The benchmarks used a gettimeofday() call which looped for at least 3 seconds. The attached PDFs shows the results in terms of "Tics per SemOp". and "SemOps per Second".

Observations:
The Opteron 270 running at 1GHz and using int 80 for system calls was the fastest per clock tic. The fastest processors (the Xeons) were the slowest. This suggests the problem is the memory access.

The raw numbers show that the sysent call on the Opteron makes the semop about 14% faster. Static compilation generally improved speeds, though because of system load, I would not put much significance on these numbers. The only dynamic linking, really, is the library call to invoke a system call.

Analysis:
I'm going to leave it to others to explain this data.