From: Kirk Sluder on
In article <1168415128.371873.262730(a)p59g2000hsd.googlegroups.com>,
"Tim Bradshaw" <tfb+google(a)tfeb.org> wrote:

> Kirk Sluder wrote:
>
> >
> > Well, just speaking as an Mac user, the benefits of multi-core CPUs
> > for desktop applications beyond simulating ecosystems has been noted
> > by consumers.
>
> I suspect you are confusing several issues here.
>
> - The first multicore (in a single socket macs were the intel boxes, so
> there are multiple near-simultaneous performance changes tangled up -
> significantly higher single-core performance, probably significantly
> better compilation technology, and multiple cores per die.

The first generation of Apple Intel hardware did offer a mix of
single-core and dual-core processors. At that time there were
comparisons made and discussion about the impact of two processor
vs. one processor systems. (And as you point out, discussion of
multiple CPUs in a system isn't new.)

> However they do care about things like battery life, noise, and system
> cost which correlate quite well with power consumption. And they
> *will* care about power consumption (even the Americans) when the
> systems start costing significantly more than their purchase cost to
> run for a year.

True. I still think that some of the demand is driven by mainstream
adoption of increasingly resource-hungry applications that had
previously required some pretty expensive custom hardware.

>
> --tim
From: Robert Uhl on
"Tim Bradshaw" <tfb+google(a)tfeb.org> writes:
>
> However they do care about things like battery life, noise, and system
> cost which correlate quite well with power consumption. And they
> *will* care about power consumption (even the Americans) when the
> systems start costing significantly more than their purchase cost to
> run for a year.

How long until that's the case? I just built a new box with a Pentium D
(said box is never turned off, ever), and the gas & electricity bill for
my entire home is still around $40-$60/month, depending on the season of
the year. And I'm a homebrewer, which means that I spend a significant
amount of electricity heating 6 1/2 gallons of liquid and boiling it
down to 5 1/4 gallons. Oh, and it's winter here in Denver, so I have to
heat my home.

--
Robert Uhl <http://public.xdi.org/=ruhl>
I have sustained a continual bombardment & cannonade for 24 hours & have
not lost a man. The enemy has demanded a surrender at discretion,
otherwise the garrison are to be put to the sword if the fort is taken.
I have answered the demand with a cannon shot, and our flag still waves
proudly from the walls. I shall never surrender nor retreat.
--William B. Travis
From: Spiros Bousbouras on
Madhu wrote:
> * "Spiros Bousbouras" <1168298748.558477.152070(a)11g2000cwr.XXXXX.com> :
> | If you want to analyse chess positions you can never
> | have too much speed and it has nothing to do with
> | rendering. I'm sure it's the same situation with go and
> | many other games.
>
> But having more than one core will not be a benefit if your algorithms
> are graph based and have to search a tree. IIRC most graph algorithms
> (dfs bfs) are inherently unparallelizable.

I don't know what algorithms are being used for
chess engines but they definitely benefit from parallel
processing. Well known programmes like Fritz , Schredder ,
Crafty etc. play better with many processors. I stumbled
upon a PhD thesis on the net once about parallel chess
playing algorithms. And of course Hydra
(http://www.hydrachess.com/main.cfm) uses many processors.

From: wv9557 on
I don't think there is anything more anti parallelism like Lisp. Lisp
is recursive, a function has to basically wait for another instance of
itself to finish before continuing. Where is the parallelism?

Kjetil Svalastog Matheussen wrote:
> On Mon, 8 Jan 2007, Ben wrote:
>
> >
> > BTW: Has anyone done any hard real time work using Lisp? How'd it go?
> >
>
> Well, sort of:
> http://www.notam02.no/arkiv/doc/snd-rt/
>
> And by "Well, sort of", I mean that its definitely hard real time, but
> perhaps not lisp, because its not consing. However, consing is definitely
> possible, and even garbage collecting is possible (if it had been
> implemented). I am however not sure how useful hard-core consing would be
> for this kind of work.

From: Christopher Browne on
Martha Stewart called it a Good Thing when "Tim Bradshaw" <tfb+google(a)tfeb.org> wrote:
> Kirk Sluder wrote:
>
>> The high-performance processors are already moving to quad core.
>
> Well, of course, the high-end processors shipped for the server market
> will always be somewhat ahead of those for desktops, as there's a
> commercially significant number of people willing to pay thousands of
> dollars per part there, while the market for desktops that expensive is
> really very small indeed (not many people buy $5-10k desktops any
> more). It takes a year or two for parts to get cheap enough to make it
> into the desktop market (and they're often lower spec in various ways -
> less cache per core etc - to get the price down further).

Note that laptop makers are starting to trumpet "Intel Dual Core!!!",
so while that may not be quad-core, they're certainly pushing in this
direction. And they're trying to at least pretend that users need
more CPU power so as to use this.

The "next generation" apps that can chew the CPU resources appear to
be compression/decompression of video and sound.

How useful that *truly* is may be questionable. Having dual cores on
my laptop doesn't make ssh sessions run perceptably faster, and that,
along with Firefox sessions, is primarily what that laptop does...

> But actually I read a review of a quad core Intel CPU which was clearly
> aimed at (high-end) desktops just the other day (though it was some
> horrible two-chips-in-one-package thing, so not actually quad core in
> any real sense at all, merely a pair of very densely packed dual-core
> CPUs). Outside of x86, 8 core CPUs have been shipping in significant
> numbers for a while.

There's a company trying to hawk systems based on 16-core MIPS CPUs.
I wish them well, but suspect it may not go well for them...

>> None of the chip makers appear to have much interest in simplifying
>> the market in that way.
>
> The point I was making is that the same basic implementation
> architecture is what will ship into both markets, not that identical
> parts will. And it's not a matter of "simplifying the market", it's a
> matter of it being far too expensive for processor vendors to develop
> entirely independent lines for markets which are so closely related.

Which is essentially how Opteron "took off," whereas IA-64 seems to be
essentially of no commercial interest.
--
output = ("cbbrowne" "@" "gmail.com")
http://cbbrowne.com/info/nonrdbms.html
Error: Keyboard not attached. Press F1 to continue.