[dundee] Opinions on the Sun Ultra 24 Box - Good bang-per-buck?

[Lee Hughes]

Rick Moynihan <rick.moynihan at gmail.com> wrote: 2008/4/25 Andrew Clayton :
>
> On Fri, 25 Apr 2008 11:38:19 +0100, Rick Moynihan wrote:
>
>  > 2008/4/25 Andrew Clayton :
>  > > On Thu, 24 Apr 2008 22:54:29 +0100 (BST), Lee Hughes wrote:
>  > >
>  > >  > yeah, but will the software (os/app's) take advantage of all that
>  > >  > threading capability?
>  > >
>  > >  I'll use the terms cores and cpu's interchangeably below..
>  > >
>  > >  Of course. Linux itself is quite capable of dealing with many
>  > > cpu's, with support for 4096 cpu's currently being worked on for
>  > > merging from the folks at SGI.
>  > >
>  > >  You want real world examples,
>  > >
>  > >  Compiling is an obvious one with make supporting parallel compiling
>  > >  natively, e.g make -j 
>  > >
>  > >  If you use a source based distribution, you'll like many cores...
>  > >
>  > >  Saw a recent reference to an IBM machine that does 3K/sec (that's 3
>  > >  kernel builds a second)
>  > >
>  > >  Grip supports multiple cpu's for encoding audio.
>  > >
>  > >  I'm sure games will start supporting multiple cores, in fact IIRC
>  > > some version of quake does/did.
>  > >
>  > >  Any java app you use...
>  > >
>  > >  And just having the capacity that comes from having multiple cores,
>  > >  video encoding not interfering with your compilation for example.
>  > >
>  > >  That heavy javascript site causing firefox to hammer one of your
>  > > cores.
>  > >
>  > >  So yeah, Linux has been ready for this for a long time and as
>  > > multiple cores become more prevalent, I'm sure more apps will be
>  > > written specifically to take advantage.
>  >
>  > This is all true, but with the current state of hardware  (at least
>  > under x86) I suspect that simply adding more CPUs & cores leads
>  > diminishing returns, due to problems with shared memory; i.e. cache
>  > and memory flushes under the hood.  Sure an 8/16 core machine sounds
>  > great, but I'm not sure if I could ever keep all the cores busy during
>  > my normal workload.
>
>  Yeah, It can depend on what your doing, long running cpu
>  intensive jobs probably make the most efficient use of multiple
>  cores/cpu's.
>
>  And I was just reading this thread,
>  http://www.ussg.iu.edu/hypermail/linux/kernel/0804.2/3300.html
>
>  "I have 128 cpus, that's 128 grabs of that spinlock every quantum. My
>  next system I'm getting will have 256 cpus."

Am I right in reading that thread as illustrating the problems of
shared memory?

The quote you pasted taken out of threads surrounding context seems to
imply something like "I'm happy with my 128 CPU's blocking on memory
writes, so I'm going to waste lots of money on 256 CPU's next time!!!"
 When I think it's really just saying, "this is really going to bite
when we have 256 CPUs!"

>  > A single quad-core CPU where each core screams speed, seems like a
>  > better investment than going for 2 processors.  The question is
>
>  Yes, a quad core is likely better than 2 single core processors.
>
>
>
hmm, interesting stuff indeed....

So you need to analyse your current workload, identify your bottlenecks, you may be I/O bound for instance..move your compilation environment onto a ram disk, and see what performance you get.

I'd still say freezing you cpu and over clocking it the way to go!!!! ;-)
maxium speed!!! :-).... 














>  _______________________________________________
>  dundee GNU/Linux Users Group mailing list
>  dundee at lists.lug.org.uk  http://dundee.lug.org.uk
>  https://mailman.lug.org.uk/mailman/listinfo/dundee
>  Chat on IRC, #tlug on dundee.lug.org.uk
>



-- 
Rick Moynihan
rick.moynihan at gmail.com
http://sourcesmouth.co.uk/blog/

_______________________________________________
dundee GNU/Linux Users Group mailing list
dundee at lists.lug.org.uk  http://dundee.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/dundee
Chat on IRC, #tlug on dundee.lug.org.uk


       
---------------------------------
Sent from Yahoo! Mail.
A Smarter Email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.lug.org.uk/pipermail/dundee/attachments/20080425/ea2629c7/attachment.html