Benedict wrote: > > A C compiler would optimize this to a right shift. Changing that to > > 'Int64.shift_right n 1' speeds up the code. > > This is easy to fix in ocamlopt (see attached patch ocamlopt- > natint.patch), by applying the same optimizations already used for > constant int's to constant natint's (Int64 is Nativeint on 64bit). Note > however, that "mod 2" is not really "and 1", neither is "div 2" > equivalent to "lsr 1"; that would be the case for unsigned arithmetic > (doesn't matter in your example, tho).
That's great. Does it optimize div and mod by any constant integer as C compilers do? > >> 1. Unboxing can give huge performance improvements on serial code, > > > > s/Unboxing/arithmetic optimizations/ > > Please find an example where the performance benefit is due to > > unboxing, and not due to arithmetic optimizations performed on the > > unboxed code. > > The boxing involved is relevant, but boxing in general is not the > issue. In this special case, the "let nlen, n = if..." code requires > heap allocation, because of the way the pattern is compiled. This could > be fixed by moving the condition out of the code and using two if's to > select n/nlen separately (doesn't speed up that much). Fixing the > pattern compiler to handle these cases might be interesting for general > benefit. > > I already mentioned this multiple times, but here we go again: Unboxing > optimizations may indeed prove useful if applied wisely (cmmgen.ml is > of special interest here, the unboxing optimizations are more or less > special cases; that could be extended to include interesting cases like > moving boxing out of if-then-else in return position, etc). > > But (here comes the special "Harrop note") this has absolutely nothing > to do with LLVM (and of course really, really, really nothing to do > with HLVM). Using a different data representation for the heap requires > a nearly complete rewrite of the OCaml system (you would probably need > to start at the Typing level); if one wants to do this, enjoy and come > back with code. But even then, data representation issues will have to > be considered long before it comes to actual code generation (if you > are serious, you'll have to think about the runtime first prior to > talking about code generation for a non-existing runtime), so even then > it has nothing to do with LLVM (or C-- or C or whatever IR you can > think of). OCaml programmers can benefit from more appropriate data representations by using LLVM as a library to generate code from OCaml. HLVM is an example of this that anyone can play with. > Combining alloc's across if-then-else constructs further reduces code > size in your example (and probably other programs as well), see > attached file ocamlopt-comballoc-ifthenelse.patch. It's quick&dirty, > but it should illustrate the idea. I think that is an even more valuable improvement to ocamlopt than the int optimization. > This doesn't mean that LLVM wouldn't be useful (in fact, I've just > started an LLVM backend for ocamlopt). But it is important to note that > LLVM is not the solution to everything. As the name implies, it's "low > level", it does a few "higher level" optimizations for C, but these are > special cases (and somewhat ugly if you take the time to read the > code). It won't make a faster OCaml magically, just like it didn't make > a faster Haskell by itself. Absolutely. > I could go on by quoting common "Harrop jokes" like "you need types in > the low-level IR", etc. trying to tell him that this is simply wrong; > but after reading through the Caml/LISP mailing list archives (thanks > for the pointers by several readers), I'm pretty much convinced that > Jon simply decided to end his war against LISP just to start a new one > against ocamlopt. Suggesting that OCaml programmers use LLVM as a library because you can get huge performance gains is hardly a "war against ocamlopt". Cheers, Jon. _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
