<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Some thoughts...</div><div><br></div><div>There was quite a lot research about this at the end of the 80s and beginning of the 90s. There are several books published about parallel programming models in Lisp.</div><div><br></div><div>To exploit parallelism in popular hardware one can see several competing areas:</div><div><br></div><div>1) <b>SIMD multimedia engines</b> (Altivec, SSE, ...). Lisp in general mostly missed this.</div><div> There were some assembler-based approaches and some Lisps are using SSE for</div><div> FP computation. Problem: different CPUs offfer different types of engines or none at all.</div><div><br></div><div> Btw., the first Connection Machines (CM1, CM2) were a giant SIMD co-processor. The host (a Vax, SUN, Symbolics)</div><div> was running a Lisp, too - controlling the Connection Machine.</div><div><br></div><div>2) <b>Multiple cores/processors</b> running concurrent threads. Research, experiments and some products in Lisp.</div><div> Due to 'Hyper-Threading' more than one thread may run on a core.</div><div><div> Currently we have laptops with two native threads (two cores). Desktop computers already are offering</div><div> 16 native threads (8 cores with two threads each / Hyper-Threading) -> Mac Pro.</div><div> CPUs may offer more threads in the coming years -> 64, 256. Existing examples are SUN's UltraSPARC T2 with</div><div> up to 64 threads.</div><div><br></div><div> The BBN Butterfly ( <a href="http://en.wikipedia.org/wiki/BBN_Butterfly_computers">http://en.wikipedia.org/wiki/BBN_Butterfly_computers</a> ) computer ran a concurrent Scheme</div><div> and on top of this a Common Lisp was implemented.</div><div><br></div></div><div>3) <b>GPUs</b>. The LARGEST source of compute power for parallel computation in desktop computers and even many laptops:</div><div> Graphic Processing Units. Apple works on that with OpenCL ( <a href="http://en.wikipedia.org/wiki/OpenCL">http://en.wikipedia.org/wiki/OpenCL</a> ), a language</div><div> for programming CPUs, GPUs and DSPs based on C. </div><div> The idea is that GPUs can be used for general purpose computing (GPGPU) ( <a href="http://en.wikipedia.org/wiki/GPGPU">http://en.wikipedia.org/wiki/GPGPU</a> ).</div><div> Some GPUs now offer more than 1000 GFlops (ATI Radeon 4890: 1360 GFLOPS). Then you may put</div><div> more than one GPU card in your desktop PC. Compare that to current CPUs offering in the range of 5 to 50 GFlops.</div><div><br></div><div> Glen Foy mentioned 512 cores in ten years from now. The GPU is here today.</div><div><br></div><div> Can't remember Lisp mentioned in the area of GPGPU.</div><div><br></div><div> Definitely computing with GPUs is very attractive for scientific processing: processing of images, videos, sound, etc.</div><div><br></div><div> Problem: this area is a moving target with rapidly changing products. Apple's Mac OS X 10.6 (Snow Leopard)</div><div> will provide the foundations in the Mac area. I guess for the Desktop and Laptop user it may bring</div><div> very interesting speed increases in the coming years, especially in computing with multimedia data.</div><div> Conversions of video formats will run on the GPU. All kinds of video effects will run on the GPU.</div><div> Music applications will render sounds on the GPU. Encryption, physics computation, rendering, etc.</div><div><br></div><div>4) <b>Distributed computing</b>: Clusters, P2P, code mobility, ... Only some research and some experiments in Lisp.</div><div> Erlang as programming language and runtime is notable in that area. </div><div><br></div><div>For some computing tasks it might not be enough to offer support for multiple concurrent threads on a CPU, when the GPU approach beats it by a factor of ten or even hundred. Most rendering, multimedia processing, etc. will move to GPUs, I'd guess.</div><div>Larger experiments are running on clusters - similar to what Dan Weinreb reports from their architectures at ITA.</div><div><br></div><div>Where does the multi-core-computing fit in? I'd say it is necessary to support it, but for many applications I would see other approaches to have advantages. Many network-applications and in the Lisp area many symbolic applications will benefit from concurrent threads.</div><div><br></div><div><br></div><div><b>More about 2)</b></div><div><br></div><div>Clozure CL currently offers some support for 2), running threads on multiple cores/processors.</div><div>There hasn't been much discussion lately of the problems of Common Lisp running on multiple cores.</div><div><br></div><div>Again, one could identify several levels of support for multi-core computing:</div><div><br></div><div><br></div><div>a) being able to run (native) threads on different cores. CCL does this.</div><div><br></div><div>b) the Common Lisp implementation is thread safe. Say, if LOAD, DEFCLASS, COMPILE, are not reentrant, it</div><div> is assured that only one can run at any one time. There is more to it, though.</div><div><br></div><div>c) Common Lisp constructs are thread safe and reentrant. Example: You could run multiple DEFCLASS (mostly) in parallel</div><div> in one Lisp.</div><div><br></div><div>d) Common Lisp supports special programming facilities: futures, queues, stm, data parallelism, etc.</div><div><br></div><div>A special challenge is the garbage collector. Today we have few concurrent threads. In the near future one</div><div>may have 64 concurrent threads running on a desktop computer CPU. That means when all 64 threads are</div><div>busy, they may produce garbage 64 times as fast as a single thread. So it might be not that clever</div><div>to run the garbage generator with 64 threads and the garbage collector with only one thread (while halting other</div><div>Lisp computation).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div><br></div><div>Rainer Joswig</div><div><br></div><br><div><div>Am 19.05.2009 um 14:05 schrieb Alexander Repenning:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>not so fast ;-)</div><div><br></div><div>The "how can we make use of multiple cores" is currently on the the hottest funding topics supported by NSF, DOE, Microsoft, .....</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>alex</div><div><br></div><div><br></div><br><div><div>On May 18, 2009, at 10:45 AM, Brian Mastenbrook wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">On Mon, 2009-05-18 at 10:13 -0400, Glen Foy wrote:<br><br><blockquote type="cite">My ignorance of compiler design is breathtaking, but could multi-core<br></blockquote><blockquote type="cite">compiler techniques be used to compensate for Intel's register-starved<br></blockquote><blockquote type="cite">architecture?<br></blockquote><br>In a word, no.</span></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Prof. Alexander Repenning</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br class="khtml-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">University of Colorado</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Computer Science Department</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Boulder, CO 80309-430</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br class="khtml-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">vCard: <a href="http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf">http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf</a></font></div><br class="Apple-interchange-newline"></span></span></span></div></span> </div><br></div>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>http://clozure.com/mailman/listinfo/openmcl-devel<br></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Rainer Joswig, Hamburg, Germany</div><div><a href="http://lispm.dyndns.org/">http://lispm.dyndns.org/</a></div><div><a href="mailto:joswig@lisp.de">mailto:joswig@lisp.de</a></div><div><br></div></div></div></div></div></div></div></div></div></div></div></span><br class="Apple-interchange-newline"> </div><br></body></html>