[Openmcl-devel] Speed, compilers and multi-core processors

[Dan Weinreb]

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 JRockit
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
then.

-- 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 
> guess.
>
> Regards,
>
> 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 execution.
>>
>> 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.
>>
>> alex
>>
>>
>>
>> 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
>>>> architecture?
>>>
>>> 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 
>> <http://www.cs.colorado.edu/%7Eralex/AlexanderRepenning.vcf>
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> Rainer Joswig, Hamburg, Germany
> http://lispm.dyndns.org/
> mailto:joswig at lisp.de
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090520/530b9e9a/attachment.htm>