I have been working on compilers professionally for more than 8 years, I did not read your ocaml code, so I am not sure it's performant ocaml code. But anyway, I think you already convinced yourself elm suits your need better :-) On Tue, Jan 24, 2017 at 11:44 PM GordonBGood <[email protected]> wrote:
> On Tuesday, 24 January 2017 09:37:32 UTC+7, Richard Feldman wrote: > > The reason is that BuckleScript proves that Arrays are faster than > "string" tagged objects and I have tried benchmarking it myself. In fact, > I have gone further and manually substituted the use of Arrays rather than > the string tagged objects in the generated Elm code to show that is the > reason. The problem isn't so much the use of Array's versus > objects/records, but the string tags, which as the Elm JS output doesn't > preserve type information except by these tags, are continuously requiring > string processing to determine the type of object at run time. Elimination > of these strings by using the type information the compiler already has > would greatly speed things even if objects are used, with the further > advantage of Arrays being that their indices are numeric for slightly less > processing (depending on the browser engine used). > > > Modern JS engines intern string literals > <http://stackoverflow.com/questions/5276915/do-common-javascript-implementations-use-string-interning>, > making them in general faster than index-based Array access. I would > definitely expect this idea to result in a performance regression for Elm, > and I would be very surprised to see benchmarks to the contrary. > > > With Robin Heggelund Hansen's help, I have determined that my problem is > primarily the issue he already raised with Evan: that the static type > information is not used in code generation so that equality and comparison > conditions require an extra level of function calls, which problem is > exacerbated by the tightness of the loops I am trying to write. In fact, > other than for this problem, JS code produced by Elm is quite fast, at > least on the Chrome V8 JS engine. > > > > My point is that for those of us that need speed - at least a few that > have chimed in on this thread - if it isn't addressed with the Elm compiler > then Elm might migrate to a front end to OCaml which would schism > development efforts and possibly hurt the language. > > My other point is that the sooner it is done the easier it will be. > > And it doesn't affect those that find current Elm speed adequate - all > that is needed is enough contributors and co-ordination between the > different developments. > > > I don't think any of this has even the remotest chance of happening. > > > Why do you think that? I see that someone named Joey Eremondi did > extensive work to improve optimization leading up to version 0.16 which > made differences from several times to hundreds of times in improved > execution speed. it turns out that I am suggesting much less than that: > just the ability to make calls to the "isPrim" function for types and if > true to just emit the direct JS operators rather than making a run time > call to the general eq/cmp functions to let it be sorted out at run time. > Further optimizations a la BuckleScript are more minor in effect and major > in execution, effectively erasing some type information for minimal cases, > but doing this would be much more complex as more complete type information > would need to be available to the Code Generator. For instance, > BuckleScript already knows the number of elements in a Tuple0 as compared > to a Tuple2 so there is no need for a tag. and the same goes for records of > various field names and numbers of fields. > > Joey's work already made Elm's handling of closures quite effective and in > some cases better than BuckleScript as to elimination of the closure when > it is inside a tail call optimized loop for many cases. > > Although off the subject of speed, it is something like the fairly minor > change to make all current Elm types comparable (if comparing like types > with like) so that Records and Union types/ADT's are also comparable as > they are in OCaml/BuckleScript: the compiler already makes sure that both > sides of a comparison are of the same type and kind; this would allow all > current Elm types to be used as keys in Dict's/Set's and perhaps reduce the > pressure on Evan to add type classes to the language. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
