Re: Next Generation of Language

sailormoontw@xxxxxxxxx wrote:

Matsu, the creator of Ruby, said in the next 10 years, 64 or 128 cores
desktop computers will be common, it's nearly impossible to simply
write that many threads, it should be done automatically, so maybe
functional language will do a better job in parallel programming than
procedural language like C or Ruby.

I think the only interesting bit of this is what people will do with
this on desktops. Server applications frequently have plenty of
parallelism to exploit and people are becoming very sensitive to power
issues (not, I think, out of any sense of responsibility but because it
is now often hard to fill racks in DCs without exceeding power &
cooling budgets, and both are also expensive of course). This is
finally driving people towards multiple core systems clocked less
aggressively (quadratic dependence of power on clock speed really makes
a difference here).

Even when there is not enough parallelism to exploit you can use
multiple-core machines to consolidate lots of less-threaded
applications efficiently, either using one of the somewhat horrible
machine-level virtualisation things or something more lightweight like
zones.

Of course, all this is predicated on there being enough memory
bandwidth that everything doesn't just starve. I dunno how good
current seriously-multicore systems are in this respect.

But on the desktop most of these applications aren't very interesting,
so finding something for a seriously multicore system to do might be
more of a challenge. There is, of course, the argument that it doesn't
matter very much: given that it's expensive to provide enough memory
bandwidth & that desktop applications are often much more latency
sensitive than server ones, but somehow desktop processors ship with
much less cache than those for servers, one has to wonder whether
anyone actually really notices. I suspect desktops already spend most
of their time either idle or stalled waiting for memory. Adding more
cores will just mean they spend more time doing both. Not that this
will stop anyone, of course.

.

Relevant Pages

  • Re: OS/2 mentioned in a Vista review
    ... channel the power and memory where I need it, which is for applications, ...
    (comp.os.os2.misc)
  • Re: xmalloc string functions
    ... require memory allocations depending on the way the system works. ... If the toolkit being used is not one of those, then it is irrelevant that some provide a means to do so, particularly if the "some" are not available for the platform being targeted. ... Not enough context for most real-world applications to recover at this point. ... At this point g_malloccalling abortbecomes a moot point, particularly if your auto-save code is robust against memory allocation errors. ...
    (comp.lang.c)
  • Re: ProDOS Plus
    ... operating system was not considered worth the problems when it was just as easy to make the applications support 128k or more ram. ... your suggested P-code system could do something similar by running in the aux 64k memory range $D000...FFFF or perhaps the aux ram used by the P8 /ram driver code space. ... the OS could fit in *only* the space that ProDOS now occupies. ... if practicality were a concern we probably wouldn't be using old hardware. ...
    (comp.sys.apple2)
  • Re: xmalloc string functions
    ... If these were the only choices (crashing applications or a frozen ... trying to malloc some rediculously large amount of memory - e.g. in the ... because their malloc wrapper decided to exit. ... Exiting on malloc failure makes sense for a utility like sort. ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... require memory allocations depending on the way the system works. ... Not enough context for most real-world applications to ... It is /more/ reliable to routinely auto-save the user's work (as you ... particularly if your auto-save code is robust against memory allocation ...
    (comp.lang.c)