What's wrong with C++ templates?

Started by
38 comments, last by SabreMan 20 years, 10 months ago
quote:Original post by Anonymous Poster
You''re trying to make a little out of a lot. ML compilers do a great job at optimization and produce code that perform as well if not better than their C++ counterparts. Go look at MLton and Ocaml. The "rule of thumb" that if it isn''t low-level it isn''t fast is a joke.


No arguments here. Although I do wonder if there is an equivalent of C++ expression objects (which is an easily optimizable construct for compilers, given the nature of C++) in other languages.

quote:
Assuming you''re still talking about dynamic vs. static typing, being able to turn it off/on is the greatest feature a language can ever have. Forcing yourself into the dichotomy of one or the other is simply unecessary.


I''m not, and, well, duh.

MSN
Advertisement
Throwing more oil into the fire.

MSN
quote:Original post by msn12b
No arguments here. Although I do wonder if there is an equivalent of C++ expression objects (which is an easily optimizable construct for compilers, given the nature of C++) in other languages.


Lazy evaluation and inlining. In functional languages lazy evaluation can be simulated, to some extent, with a no-argument function wrapper called a thunk.

(define f  (lambda (x)    (car x)))(f (lambda () (cons 1 ''())))
Just a side question to SabreMan, I''m not trying to be mean or anything, but what justifies the low score of Lisp at language shoot outs? Clearly whatever you try to do, OCaml is "better". I have programmed with lisp little bit, but can you explain this?

link
win32
http://dada.perl.it/shootout/
"Portable"
http://www.bagley.org/~doug/shootout/
quote:Original post by Captain Goatse
Just a side question to SabreMan, I''m not trying to be mean or anything, but what justifies the low score of Lisp at language shoot outs?

I don''t know. In the two links you provided, they use poplisp which I''ve never encountered before, and CMUCL, which I''m not very familiar with. I didn''t do too much investigation into the shoot-outs, as I tend to take such things with a pinch of salt, but here''s some things that you can do to improve performance of Common Lisp programs:


  • Optimisation advice can be introduced into segments of the program, at almost any level of granularity. This can involve things like trading bounds-checking for speed.

  • Compiler settings are available (as part of the Standard) for what level of speed, safety, size, etc, is required for the program.

  • Optional type-declarations can be added, which the compiler may use to perform optimisations.



I don''t know about the quality of the Lisp implementations used, and I don''t know the details of what they did to ensure good performance of the programs written (including whether the programmer knows how to write efficient programs).
quote:Original post by msn12b
What I should have said is the runtime environment of Lisp and ML, mainly safety checks, keep those languages, when compiled, to reach the same level of performance of a comparable C/C++ program. Part of the price you pay for a language runtime that has dynamic typing is extra code and data necessary to make such a system work, e.g. runtime function call validation or generic object function calls.

I''m afraid this is more vague hand-waving, and not the specifics I asked for. Lisp allows you to do provide compiler settings for things like speed and safety, so that you can trade one for the other. As the AP said, you can also introduce declarations which the compiler might employ for deducing how best to optimise a program.
quote:Original post by Captain Goatse
Just a side question to SabreMan, I''m not trying to be mean or anything, but what justifies the low score of Lisp at language shoot outs?

This might also be of interest.
The language shootout does everything "the same way" in each language. This means they all use they stick to the same method wherever possible and don''t use the unique features found in different languages. Go look at the Scheme programs. They don''t use tail-recursion for iteration. I''d rather see a test done where things were done the way the language designers intended as the most natural way, not the way that most resembles basic C (nearly all the source posted on the shootout page does).
quote:Original post by SabreMan
This might also be of interest.


Thanks for the link. I just thought I''d mention an interesting application of Lisp/dynamic compilation that was mentioned near the bottom of that thread. Regular expressions. At any time you can take a regular expression string and transform it into equivalent lisp code, compile that code into a function, and apply the function in your program. That''s the first really impressive use of Lisp macros I''ve seen. My time with Lisp has been short though, maybe more experienced people here can name others?
quote:Original post by Dobbs
Thanks for the link. I just thought I''d mention an interesting application of Lisp/dynamic compilation that was mentioned near the bottom of that thread. Regular expressions. At any time you can take a regular expression string and transform it into equivalent lisp code, compile that code into a function, and apply the function in your program. That''s the first really impressive use of Lisp macros I''ve seen. My time with Lisp has been short though, maybe more experienced people here can name others?


Any time you can include the development environemnt in the runtime environment you can do some really cool stuff.

MSN

This topic is closed to new replies.

Advertisement