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

Dan Weinreb dlw at itasoftware.com
Thu May 21 10:33:32 PDT 2009

mikel evins wrote:
> Clojure and Common Lisp both do the same thing that Haskell does: they  
> take away certain facilities because their absence makes certain  
> solutions workable.
Indeed, and what's more, practical Common Lisp programmers are even
more restrictive than that.  For example, we rarely use "eval" and
we very, very rarely write self-modifying code.  You'd be surprised
how many people out there, who have had a bit of exposure to Lisp
but not any real exposure, don't know that, and assume that Lisp
cannot be compiled, etc.
> Concurrency is different from memory management in this respect only  
> because multiple cores have become cheap and widespread long after  
> large memories did. GC is a solution to the robustness and  
> productivity problems caused by manual memory management. STM is a  
> solution (one of several) to the robustness and productivity problems  
> caused by manual concurrency management.
Yes, exactly.
> There are certainly many programs that don't involve a lot of  
> concurrency, but Moore's law is over, and chipmakers are giving us  
> more cores now instead of faster ones. Sure, some people will always  
> want to manage their threads manually, just as some people will always  
> want malloc and free. But some like GC, because it makes a bunch of  
> headaches go away, and the cost of giving up malloc and free goes down  
> all the time. As cores multiply, the same thing will happen for  
> facilities that do for concurrency what GC does for memory management.
In all fairness, there are some programs that are extremely
easy to parallelize, and you hardly need any locks or
transactions or anything.  Our system at ITA just runs
8 Lisp processes on a 8-core machine, and none of
those processes treats any of the other 7 differently
than it treats the other members of the cluster running
on separate boxes.

But there are other programs that do want to use
closely-coupled algorithms on multiple cores,
and those are the ones we've been talking about.
> Jeremy suggested that someone could implement a Common Lisp designed  
> around Clojure's concurrency features. You said you hoped not; I don't  
> think you have anything to worry about. I don't think bolting  
> Clojure's concurrency features onto Common Lisp buys much. Clojure's  
> concurrency features work well because they're part of a package deal.  
> I think it's pretty hard to fit that package deal into Common Lisp. I  
> can imagine a Lisp other than Clojure that would fit it, but it  
> wouldn't be Common Lisp.
I agree completely.
> - Dan
> --me
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list