Browse thread
[Caml-list] Does Caml have slow arithmetics ?
-
Diego Olivier Fernandez Pons
- Richard Jones
-
Basile Starynkevitch [local]
- Diego Olivier Fernandez Pons
-
Evgeny Chukreev
-
Xavier Leroy
- Evgeny Chukreev
-
skaller
- David Brown
- Alex Baretta
- Jon Harrop
-
Xavier Leroy
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] Does Caml have slow arithmetics ? |
On Thu, 2004-07-08 at 13:44, David Brown wrote: > > Of course that argument fails totally in one important > > case -- Q: if you wanted a loop why didn't you use one? > > A: tail-rec functional code is considered cute :) > > In some functional languages (Scheme, specifically), tail recursion is > required to be implemented iteratively. It is a common enough idiom, > and easy enough to implement, that it is generally done in functional > languages. In fact, gcc does it in C, with enough optimization. I'm aware of this, my point is that Xavier's argument that complex code generates inefficient code "what else do you expect?" is a bit weak. Whether you expect tail-rec optimisation or not depends on your knowledge of compiler implementation details. Felix for example has a functional subsystem which one could argue is "more functional" than Ocaml's since side effects are not permitted .. but it happens to generate C at the moment -- and I admit I myself have no idea whether tail calls in functions are optimised or not, or how to actually organise the generated C so as to encourage a compiler .. perhaps gcc, perhaps MSVC .. to actually perform the optimisation. Procedure calls ARE tail-rec optimised by Felix (guarranteed!) but the calling mechanism is quite different to that used for functions. Even experts are often surprised by generated code complexity. In C++ for example, the close connection between source and generated code is lost in some cases, particularly constructor calls: the cost of instantiating a class with virtual bases and functions derived from others can be extremely high and is silently hidden .. and C++ experts often miss the disparity between source and generated code. Note I'm not disputing Xaviers orientation here: I basically agree, I merely wish to point out that the argument isn't quite as strong as one might think. Higher level optimisations are also important IMHO. Chosing which ones to actually do is of course very hard :) -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners