[Caml-list] Re: Is OCaml fast?
>>> I think OCaml's problem with this benchmark do point at a weakness >>> of the current GC code. > What makes you think that ? I don't really understand the question: it was just stating the obvious. OCaml's GC (including its default settings) is generally very good, but like all GCs it has its weaknesses. This is fundamentally unavoidable. There should be no shame admitting that this particular case hits one of those weak spots. Stefan ___ 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
[Caml-list] Re: Is OCaml fast?
> Richard's objection, which you dismissed out of hand, was that your > no-GC-tuning rule is silly in the light of actual uses of garbage > collected programming languages on modern processors. It makes your > results unrealistic, and an unrealistic benchmark is misleading, or at > best merely useless. To the extent that this rule is the same for all languages and that most languages on the shootout are also garbage collected, I think OCaml's problem with this benchmark do point at a weakness of the current GC code. Of course, the shootout could be improved. E.g. maybe it could allow extra submissions that break the rules, along with a description of which rules were broken and how. Then there could be a "score according to the rules", then a "score when all gloves are off", together with some kind of "measure" of what was needed to go from one to the other. This way people could maybe get a better feel for the languages's performance and how (and how much) that performance can be affected. Doesn't seem like an easy undertaking, tho. Stefan ___ 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
[Caml-list] Re: Generalized Algebraic Datatypes
> type _ t =
> | IntLit : int -> int t
> | BoolLit : bool -> bool t
> | Pair : 'a t * 'b t -> ('a * 'b) t
> | App : ('a -> 'b) t * 'a t -> 'b t
> | Abs : ('a -> 'b) -> ('a -> 'b) t
> There's something "Haskellish" about this syntax, in the sense that type
> constructors are portrayed as being like functions.
Indeed IIRC OCaml does not accept "App" as an expression (you have to
provide arguments to the construct). Maybe this is a good opportunity
to lift this restriction.
> While this does make sense in Haskell, in Ocaml it feels a bit out of
> place, because you cannot, for example, partially apply
> a type constructor.
The types above don't allow partial applications either. They use the
OCaml/SML style of constructors were partial application is not possible
because the various arguments are not provided in a curried way.
Stefan
___
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
[Caml-list] Re: AGI research using ocaml
>> 4) You would like to generate OCaml program fragments instead of Scheme. >> Your idea is that the type system, imposing more constraints on the legal >> program, will reduce the search space and accelerate your generator. > Absolutely. For simpler function induction problems, I assume this > could even be done automatically by inducing type constraints over a > set of examples. Part of future research, I think. I am afraid I'll > have to read many programming language papers! Depending on how you want to use types, it can help, but not necessarily: If you manage to use types to restrict your search, then that's great, since your programs will be properly typed by construction (and the host language may even know that, e.g. using GADTs or something equivalent) and you may indeed be able to interpret them faster. But if you don't, then you end up with programs which may or may not be properly typed, in which case types will allow you to reject programs before running them, but at the cost of having to type-check every program. So if the run time of each program is short compared to the program's size, it may end up more costly to type-check the code than to just run it. Stefan ___ 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
[Caml-list] Re: The need to specify 'rec' in a recursive function defintion
> It sure does, tho not with "fun" but only with "var" definitions. ^^^ val Stefan "blush!" ___ 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
[Caml-list] Re: The need to specify 'rec' in a recursive function defintion
>> Till Varoquaux had written: >> > Let's make things clear here: the "rec" *really* is a feature; >> Nobody said otherwise. Eliminating the "rec" is also a feature. >> Those two features are mostly incompatible, and many reasonable people >> disagree on which one of the two is more important. >> Stefan "who extensively used that feature in SML, but happens >> to prefer the other feature nevertheless" > Standard ML doesn't have the feature that Till described. It sure does, tho not with "fun" but only with "var" definitions. Stefan ___ 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
[Caml-list] Re: The need to specify 'rec' in a recursive function defintion
>>> Wouldn't one of way of detecting a recursive function would be to see >>> if the indeed the function calls itself? >> That's what Haskell does, yes. > Let's make things clear here: the "rec" *really* is a feature; Nobody said otherwise. Eliminating the "rec" is also a feature. Those two features are mostly incompatible, and many reasonable people disagree on which one of the two is more important. Stefan "who extensively used that feature in SML, but happens to prefer the other feature nevertheless" ___ 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
[Caml-list] Re: The need to specify 'rec' in a recursive function defintion
> Wouldn't one of way of detecting a recursive function would be to see > if the indeed the function calls itself? That's what Haskell does, yes. Stefan ___ 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
[Caml-list] Re: Scilab: Why not written in OCaml?
>> ...why is that program not written with INRIA's Ocaml? > Probably for the same reason than all Princeton university > programs are not written in SML/NJ (so I guess) ? They're not? Stefan ___ 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
[Caml-list] Re: Ocamlopt x86-32 and SSE2
> As far as I know, one is using ocamlopt to improve performance. > I can't think of any case where one would need native code running on > pre-SS2 machines which are so outdated performance-wise. You mean we should make slow machines even slower? Stefan ___ 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
[Caml-list] Re: stl?
> Less than it might seem. First of all, you have the allocation costs to > hold the new vector- there's 3-5 clocks right there. Let's say the vectors > are 3 elements long. So you have six loads and three stores- > assume stores are free, and loads cost 1 clock apeice- they're in L1 cache, > and they're getting preloaded. Plus the 3 clocks for the floating point > adds. So that's 12-15 clock cycles right there. Say I'm being pessimistic > by a factor of 2, and it's really only 6-8 clock cycles. Vr.s 10 clock > cycles or so for the call via functor. Now we're down into the realm of > only doubling the cost of the operation, not an order of magnitude increase. > A single mispredicted branch or L1 cache miss that has to go out to L2 > cache- not even main memory, just L2!- would blow the overhead of calling > via functor out of the water. This presumes that the indirect function call only happens once per vector. But it may very well be once per vector plus once per element (think of parameterizing list traversal over `map': since it's abstracted, not only is the call to `map' indirect, but map's own calls to the loop body are indirect as well). Stefan ___ 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
[Caml-list] Re: What is a future of ocaml?
> I'm afraid the combination of type classes with modules and functors > is not trivial either. Actually, in "Modular Type Classes", Derek Dreyer et al. argue fairly convincingly that they can be combined in a natural way. Of course, there's still the question of whether it all works out when you add objects, polymorphic variants, ... Stefan ___ 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
[Caml-list] Re: Emacs 22.3.1 + tuareg + fold-mode
> Now, with Emacs 22.3.1, tuareg-mode (1.45.6) and fold-mode no longer work > together, the folding just does not happen. With xemacs, it works Looks like an Emacs bug. Why don't you M-x report-emacs-bug ? Stefan ___ 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
