[Openmcl-devel] Speed, compilers and multi-core processors
dlw at itasoftware.com
Wed May 20 14:12:36 EDT 2009
One source says that CUDA can do anything you can do in C
other than function pointers and recursion. Probably this
means no stack, locals are allocated at fixed addresses
just like globals, each procedure has one global cell
as a return address, etc.
Dan Weinreb wrote:
> Rainer Joswig wrote:
>> sm, etc.
>> A special challenge is the garbage collector. Today we have few
>> concurrent threads. In the near future one
>> may have 64 concurrent threads running on a desktop computer CPU.
>> That means when all 64 threads are
>> busy, they may produce garbage 64 times as fast as a single thread.
>> So it might be not that clever
>> to run the garbage generator with 64 threads and the garbage
>> collector with only one thread (while halting other
>> Lisp computation).
> There's been a lot of interesting work done in that area, too. The
> implementation of the Java Virtual Machine has both "concurrent" and
> "parallel" GC technology, which I believe has been published by the
> people who did it. (The company is in, I think, Sweden, and was
> bought by BEA (when I worked there), which in turn was bought
> by Oracle. You can still get it for free from Oracle, I'm pretty sure.)
>> It would also be interesting to identify general issues with Common
>> Lisp with respect to implementing it with multiple concurrent threads
>> - for example to compare implementations and to identify areas where
>> implementations need to do something.
> I once asked Gary Byers about how CCL deals with the issue that
> the Java people refer to as the "memory model". He sent me an
> answer that I didn't quite grasp, and then I dropped the conversation,
> but I'm still interested. The Java Language Spec had a number of
> rules intended to make sure everything was well-defined in the
> face of complicated cache coherency, not to mention compilers
> that re-order operations, and so on. The original memory model
> was found to have some bad properties, and William Pugh of
> U. Delaware (I think) discovered these problems and figured
> out how to fix them. I don't know what's happened since
> -- Dan
>> A useful 'conservative' approach is to advance the capabilities for
>> programming with concurrent threads. But if a user's application
>> domain offers chances for parallel computation, concurrent threads
>> might not be the best answer. For the average user, the GPU approach
>> could make a big difference in user experience in the next years - my
>> Rainer Joswig
>> Am 19.05.2009 um 14:05 schrieb Alexander Repenning:
>>> not so fast ;-)
>>> The "how can we make use of multiple cores" is currently on the
>>> the hottest funding topics supported by NSF, DOE, Microsoft, .....
>>> Perhaps it is the Lisp way to look at architectures such as the x86
>>> and see mostly limitations when indeed there are plenty of
>>> opportunities. This is not about registers but about enabling end
>>> user programmers such as scientists to make use of parallelism. The
>>> big question is how to reconceptualize programming. One of the main
>>> problems is the need to overcome bad algorithmic assumptions
>>> especially the use of unnecessary loops. For instance, in
>>> Bioinformatics textbooks are full of loop based implementations of
>>> algorithms dealing with huge data structures such as gene sequences.
>>> In many cases one could replace sequential loops with parallel
>>> Zoom out of the low level view of things. What could multi core Lisp
>>> do? Look at the computational challenges that users are dealing
>>> with. Try to come up with new computational paradigms that could
>>> help. Lisp could be a great platform to explore these
>>> issues. Careful: if you can contribute to this you may actually
>>> receive funding.
>>> On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote:
>>>> On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote:
>>>>> My ignorance of compiler design is breathtaking, but could multi-core
>>>>> compiler techniques be used to compensate for Intel's register-starved
>>>> In a word, no.
>>> Prof. Alexander Repenning
>>> University of Colorado
>>> Computer Science Department
>>> Boulder, CO 80309-430
>>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>> Rainer Joswig, Hamburg, Germany
>> mailto:joswig at lisp.de
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel