On Jul 23, 3:37 pm, gavino <·········@gmail.com> wrote:
> http://www.foxnews.com/story/0,2933,290403,00.html
No, it's not FUD. Patterson (quoted in the article) doesn't mess
around with FUD. (Remember RAID? That's him. Remember RISC? That's
him.) In fact, this is old news -- though it should be read with the
understanding that microprocessor performance isn't the most important
thing for a lot of consumer applications.
mfh
gavino wrote:
> http://www.foxnews.com/story/0,2933,290403,00.html
Need to keep that "keep up with the Jones" pressure alive and kicking in
the consumer market, don't they.
gavino <·········@gmail.com> wrote:
> http://www.foxnews.com/story/0,2933,290403,00.html
Hence the Erlang articles on planet.lisp.org
--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
gavino <·········@gmail.com> writes:
> http://www.foxnews.com/story/0,2933,290403,00.html
Not exactly.
It misses, of course, the point that while 8-core processors may not
always make applications linearly faster, there should be some
"reducing slowdowns" effect, that is, that activities that might have
otherwise slowed the system down shouldn't have as much effect...
An alternative description would be that the increase in numbers of
processors should allow performance of systems to become smoother...
--
output = ("cbbrowne" ·@" "ca.afilias.info")
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)
Christopher Browne <········@ca.afilias.info> writes:
> gavino <·········@gmail.com> writes:
>> http://www.foxnews.com/story/0,2933,290403,00.html
>
> Not exactly.
>
> It misses, of course, the point that while 8-core processors may not
> always make applications linearly faster, there should be some
> "reducing slowdowns" effect, that is, that activities that might have
> otherwise slowed the system down shouldn't have as much effect...
>
> An alternative description would be that the increase in numbers of
> processors should allow performance of systems to become smoother...
These systems, do they have 8 hard disks and 8 buses?
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
On Jul 24, 8:28 am, Pascal Bourguignon <····@informatimago.com> wrote:
> > It misses, of course, the point that while 8-core processors may not
> > always make applications linearly faster, there should be some
> > "reducing slowdowns" effect, that is, that activities that might have
> > otherwise slowed the system down shouldn't have as much effect...
If the cores don't have shared caches, then you might actually get
"superlinear speedup," if the larger number of processors allows the
data to be partitioned into small enough chunks that each chunk now
fits in cache.
> These systems, do they have 8 hard disks and 8 buses?
Haha, good point ;-) Folks are thinking about the buses problem at
least. I think Intel for their 80-core monster was talking about
stacking a local DRAM on top of each of the cores. Now you have a
network and you can dust off your old MPI codes and deploy them
again ;-P
mfh
Pascal Bourguignon <···@informatimago.com> writes:
> Christopher Browne <········@ca.afilias.info> writes:
>
>> gavino <·········@gmail.com> writes:
>>> http://www.foxnews.com/story/0,2933,290403,00.html
>>
>> Not exactly.
>>
>> It misses, of course, the point that while 8-core processors may not
>> always make applications linearly faster, there should be some
>> "reducing slowdowns" effect, that is, that activities that might have
>> otherwise slowed the system down shouldn't have as much effect...
>>
>> An alternative description would be that the increase in numbers of
>> processors should allow performance of systems to become smoother...
>
> These systems, do they have 8 hard disks and 8 buses?
Dunno. Don't care.
To the extent to which system performance may have been "jittery" due
to variations in CPU load, 8 cores should make it smoother.
The fact that having 8 hard drives or 8 SATA buses or 8 of whatever
else might have further/similar effects is not particularly germane to
the point.
--
output = ("cbbrowne" ·@" "linuxfinances.info")
http://www3.sympatico.ca/cbbrowne/rdbms.html
"A lot of people come to this newsgroup and do nothing but complain
about Lisp. I think maybe they are such heavy complainers that they
think they read comp.lain.lisp." -- Erik Naggum
In article <··············@dba2.int.libertyrms.com>,
Christopher Browne <········@ca.afilias.info> wrote:
> Pascal Bourguignon <···@informatimago.com> writes:
> > Christopher Browne <········@ca.afilias.info> writes:
> >
> >> gavino <·········@gmail.com> writes:
> >>> http://www.foxnews.com/story/0,2933,290403,00.html
> >>
> >> Not exactly.
> >>
> >> It misses, of course, the point that while 8-core processors may not
> >> always make applications linearly faster, there should be some
> >> "reducing slowdowns" effect, that is, that activities that might have
> >> otherwise slowed the system down shouldn't have as much effect...
> >>
> >> An alternative description would be that the increase in numbers of
> >> processors should allow performance of systems to become smoother...
> >
> > These systems, do they have 8 hard disks and 8 buses?
>
> Dunno. Don't care.
>
> To the extent to which system performance may have been "jittery" due
> to variations in CPU load, 8 cores should make it smoother.
>
> The fact that having 8 hard drives or 8 SATA buses or 8 of whatever
> else might have further/similar effects is not particularly germane to
> the point.
Christopher, you initially replied to the troll Gavino.
Your postings have nothing to do with Lisp. To further improve
the signal to noise ratio, you might want to discuss this topic
somewhere else. Would that be possible? Thanks.
--
http://lispm.dyndns.org
Blockwart Joswig wrote:
> To further improve the signal to noise ratio, you might want to
> discuss this topic somewhere else.
I've got a couple more suggestions on how to improve the S/N...