MLUG: Re: [MLUG] Anyone got a fast modern computer
Re: [MLUG] Anyone got a fast modern computer
Email address obfuscation in effect -- please click here to turn it off.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thanks.  Yes it does look like the various threads are working against 
each other.  I will try to rewrite the program to see if I can mitigate 
this effect.  Should have a version 1.16 out in a few days.

It might also be that the very recent linux kernels are very good at 
handling multithreading.

On Sat, 5 Jul 2008, Adam Procter wrote:

> Stephen Montgomery-Smith wrote:
>> Look at the output of the 3rd program - it spent more time on sys than
>> user!  Probably means that the multiple multithreading creates more work
>> than it saves!  Probably copying cache from one core to another!
>>
>> And the output of the 4th program - it looks like the computer usage was
>> about 1000%!  That's not bad.  Although the timings aren't great.  Maybe
>> that would run about as well with fewer threads - who knows.
>>
>>
>
> Yup, top was showing about 1000% the whole time (usually just slightly
> over).
>
> Just got done running with gcc-4.1.2 and -march=nocona, and the
> improvement was pretty slight. I might be doing something really dumb,
> for all I know -- I don't know much about parallel processing.  :) I'll
> send you records.txt off-list. Let me know if there are any other
> compiler flags you want to try.
>
> I was thinking one good thing to try would be to rig up a script that
> varies NR_THREADS and holds everything else constant, but unfortunately
> there's a hard ulimit of 80 minutes per thread on this machine, so
> reducing the number of threads may put me over that limit. Nevertheless,
> I'll give it a try with ten and eight threads -- the high sys time
> (would copying cache actually be counted there?) almost makes me wonder
> if the extra thread synchronization overhead isn't actually slowing
> things down.
>
> 'Course the server itself is a couple years old, so it might be that the
> CPUs are simply not as fast as they might be. Can any hardware gurus
> decipher/comment on the following?
>
> processor       : 15
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 4
> model name      :                   Intel(R) Xeon(TM) CPU 2.80GHz
> stepping        : 8
> cpu MHz         : 2793.159
> cache size      : 1024 KB
> physical id     : 3
> siblings        : 4
> core id         : 7
> cpu cores       : 2
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 5
> wp              : yes
> 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 syscall
> nx lm pni monitor ds_cpl est cid cx16 xtpr lahf_lm
> bogomips        : 5586.19
> clflush size    : 64
> cache_alignment : 128
> address sizes   : 40 bits physical, 48 bits virtual
> power management:
>
> (x16, of course)
>
>
>> By the way, if your machine is really a nocona machine, then
>> -march=native means the same thing.  Nevertheless, I do suspect that in
>> this arena that the more modern compilers really have made dramatic
>> improvements, even if no -march is used.  (For the lurkers, -march
>> specifies the architecture.)
>>
>
> Ahh, I gotcha. I *think* nocona is right for this machine, but I'm not
> completely sure. Anyone know if there's a utility that will figure this
> out automatically without the need to build all of gcc-4.2? Seems the
> best source I can find is this: http://gentoo-wiki.com/Safe_Cflags
>
> Adam
>
> _______________________________________________
> members mailing list
> EMAIL:PROTECTED
> http://mlug.missouri.edu/mailman/listinfo/members
>

_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members