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

[Dan Weinreb]

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 
> 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
>>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/ec65eb89/attachment.htm>