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

[Dan Weinreb]

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
>