a potential lisp convert, and interpreting the shootout
in [Lisp]
|
Prev: Pocket Lisp Machine
Next: Next Generation of Language
From: Rahul Jain on 3 Oct 2006 13:47 "Henry Bigelow" <hrbigelow(a)gmail.com> writes: > hi jon, > >> You may be interested in my ray tracer benchmarks: >> >> http://www.ffconsultancy.com/free/ray_tracer/languages.html > > thank you! very enlightening. i read the analysis. i have a few > questions about this excerpt > > "However, the designers of the ML family of languages (including OCaml > and SML) deliberately avoided some of the functionality provided by > Lisp in order to facilitate static type checking and improve > performance." > > i guess i misunderstood something. does lisp not have any type > inference? or does it have partial type inference if you explicitly > declare the types for some variables and not others? What do you mean by "Lisp"? The standard does not require type inference, as it's merely a way to optimize code by eliding type dispatches at run time and allowing the inlining of the implementation of the operator for that specific type. Lisp has a much richer type system than any of the MLs. CMUCL, for example, can do type inference to determine whether the arcsin of a value rounded off to the nearest integer will fit in a machine word or whether it might need to have a bignum (MLs don't have bignums as part of the language). For example, if we compile the following: (defun test (x y) (declare (type (integer 5 100) x) (type (integer 1 5) y)) (expt x y)) CMUCL tells us (among other things): Function: #<Function TEST {582F61C9}> Function arguments: (x y) Its defined argument types are: ((INTEGER 5 100) (INTEGER 1 5)) Its result type is: (INTEGER 5 10000000000) Therefore, it has figured out that an integer from 5 to 100 raised to the power of an integer from 1 to 5 gives us an integer from 5 to 10000000000. It can then use this information to determine whether to return a boxed (with type information if the result can overflow a register) or unboxed (raw value in a register) value. As an exmaple of this, we can compile the following: (defun test (x y) (declare (optimize speed (safety 0)) (type (integer 5 1000000) x) (type (integer 1 5000000) y)) (* x y)) and the compiler tells us: ; Note: Forced to do GENERIC-* (cost 30). ; Unable to do inline fixnum arithmetic (cost 4) because: ; The result is a (INTEGER 5 5000000000000), not a FIXNUM. ; Unable to do inline (signed-byte 32) arithmetic (cost 5) because: ; The result is a (INTEGER 5 5000000000000), not a (SIGNED-BYTE 32). ; etc. Delete a few zeroes from each of the upper bounds and the note goes away, as the * can be inlined (in the dissasembly, we see: C9: IMUL EDX, EDI instead of: 7E: CALL #x100002D0 ; #x100002D0: GENERIC-* This topic is VERY, VERY important to optimizing Lisp numeric code, so be SURE to study it carefully. -- Rahul Jain rjain(a)nyct.net Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain on 3 Oct 2006 13:53 JShrager(a)gmail.com writes: > Much as I appreciate Paolo's nod to BioBike, let me second Robert's > recommendation of R if all you need to do is crunch a bunch of numbers > that represent a bayes net. R has a quasi-reasonable quasi-Lisp > programming language and numerous packages to support mathematical and > statistical computing (incl. extensive bayesian machinery). I'm sure you know this, but the OP might find it interesting:. it's not by accident a quasi-Lisp. It's an open source C port of S, which was written in Lisp, according to what I gather. -- Rahul Jain rjain(a)nyct.net Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain on 3 Oct 2006 13:56 "Javier" <javuchi(a)gmail.com> writes: > Henry Bigelow ha escrito: >> i have zero lisp experience. i started with perl, then c++, then >> o'caml. a few days ago i read paul graham's summary of john mccarthy's >> paper, and then started reading the original, and On Lisp. i'm >> completely wowed, and would love to use it to write my programs. > > Why not first start learning with Practical Common Lisp? On Lisp is > more advanced and focused on macros. > > http://www.gigamonkeys.com/book/ Personally, I would recommend PAIP for the subject matter he's dealing with. PAIP deals more with information processing. PCL is much broader and covers parts of what both PAIP and On Lisp cover, in addition to general application building. That said, PCL is a great book, and would probably complement PAIP nicely for him. -- Rahul Jain rjain(a)nyct.net Professional Software Developer, Amateur Quantum Mechanicist
From: Henry Bigelow on 3 Oct 2006 22:22 Rahul Jain wrote: > > "However, the designers of the ML family of languages (including OCaml > > and SML) deliberately avoided some of the functionality provided by > > Lisp in order to facilitate static type checking and improve > > performance." > > > > i guess i misunderstood something. does lisp not have any type > > inference? or does it have partial type inference if you explicitly > > declare the types for some variables and not others? > > What do you mean by "Lisp"? The standard does not require type > inference, as it's merely a way to optimize code by eliding type > dispatches at run time and allowing the inlining of the implementation > of the operator for that specific type. i don't know what i mean by lisp. :) or what the standard defines. does the standard require that "lisp can be written in itself" as paul graham says (whatever that means)? and, is that why somehow has a drawback that aggressive type inference can't be done, with any compiler of lisp. > > Lisp has a much richer type system than any of the MLs. CMUCL, for > example, can do type inference to determine whether the arcsin of a > value rounded off to the nearest integer will fit in a machine word or > whether it might need to have a bignum (MLs don't have bignums as part > of the language). yes, but it's been mentioned several times that, in order to get lisp code to run fast, you have to "litter it with type declarations". so, it seems, there isn't much type inference going on. also, i got that idea from this wikipedia page: http://en.wikipedia.org/wiki/Type_system about halfway down it mentions this: Static typing usually results in compiled code that executes more quickly. When the compiler knows the exact data types that are in use, it can produce machine code that just does the right thing. Further, compilers in statically typed languages can find shortcuts more easily. Some dynamically-typed languages such as Common Lisp allow optional type declarations for optimization for this very reason. Static typing makes this pervasive. See optimization. > > For example, if we compile the following: > (defun test (x y) > (declare (type (integer 5 100) x) > (type (integer 1 5) y)) > (expt x y)) > > CMUCL tells us (among other things): > Function: #<Function TEST {582F61C9}> > Function arguments: > (x y) > Its defined argument types are: > ((INTEGER 5 100) (INTEGER 1 5)) > Its result type is: > (INTEGER 5 10000000000) > > Therefore, it has figured out that an integer from 5 to 100 raised to > the power of an integer from 1 to 5 gives us an integer from 5 to > 10000000000. It can then use this information to determine whether to > return a boxed (with type information if the result can overflow a > register) or unboxed (raw value in a register) value. > that is neat. i'd never heard of that before. > > As an exmaple of this, we can compile the following: > (defun test (x y) > (declare (optimize speed (safety 0)) > (type (integer 5 1000000) x) > (type (integer 1 5000000) y)) > (* x y)) > > and the compiler tells us: > ; Note: Forced to do GENERIC-* (cost 30). > ; Unable to do inline fixnum arithmetic (cost 4) because: > ; The result is a (INTEGER 5 5000000000000), not a FIXNUM. > ; Unable to do inline (signed-byte 32) arithmetic (cost 5) because: > ; The result is a (INTEGER 5 5000000000000), not a (SIGNED-BYTE 32). > ; etc. > > Delete a few zeroes from each of the upper bounds and the note goes > away, as the * can be inlined (in the dissasembly, we see: > C9: IMUL EDX, EDI > instead of: > 7E: CALL #x100002D0 ; #x100002D0: GENERIC-* > > > This topic is VERY, VERY important to optimizing Lisp numeric code, so > be SURE to study it carefully. i see. that's pretty cool. so, what is your programming style? do you first prototype something without any type declarations, and then add in a few in the compute-intensive code? thanks, henry > > -- > Rahul Jain > rjain(a)nyct.net > Professional Software Developer, Amateur Quantum Mechanicist
From: Jon Harrop on 4 Oct 2006 07:29
Rahul Jain wrote: > Lisp has a much richer type system than any of the MLs. I'm not sure what you mean by that. ML does lots of things that Lisp does not and vice-versa. > CMUCL, for > example, can do type inference to determine whether the arcsin of a > value rounded off to the nearest integer will fit in a machine word or > whether it might need to have a bignum ML doesn't have a numeric tower. You have to explicitly state that you want an int, float, bignum and so on. > (MLs don't have bignums as part of the language). OCaml, SML and F# all have bignums as part of the language. > This topic is VERY, VERY important to optimizing Lisp numeric code, so > be SURE to study it carefully. In contrast, succinct ML is typically fast ML. -- Dr Jon D Harrop, Flying Frog Consultancy Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists |