On Friday, 27 January 2017 09:13:12 UTC+7, Bob Zhang wrote: > > As I said, you already get convinced elm is better for you, then happy > coding in elm. I am not interested in a biased judgement.
Hongbo, I'm making no judgement at all other than for the facts I see and the analysis I make based on those facts. The fact is that I have two as much as possible identical implementations of a functional tree folding Sieve of Eratosthenes primes algorithm since you didn't like what I did with the Hamming numbers one, one written in Elm and the other in BuckleScript. Another set of facts are that when run on Chrome or Edge, they have similar performance or at least small performance differences that are easily understood for the known differences in the emitted code, but when compared on Firefox, the BS version is about five times slower than the Elm version. I thought you would like to look at the code and tell me if I am doing something wrong or look into it if it is a BS issue, which it is. I no longer believe it has anything to do with the use of Array's versus the use of Record's, as other facts are that I wrote simple versions in pure JavaScript using each of Array's and Record's (without tags and without currying) and the times do not change significantly for any given browser and Firefox is then very fast. I have also manually edited the BS code to eliminate any small differences that could make any difference in execution time such as unnecessary closures and polyfills to little effect. This leaves the biggest possibility for the difference in performance on FireFox as the differences between how the two languages implement currying. Now I know that I can force BS to not use Currying by using the [@bs] notation, which if I did would very likely make BS run at its normal fast speed, but as you said before, since Elm doesn't have such notations it wouldn't be comparing like-with-like. However, I did it anyway (adding 22 [@bs] notations) and that made the code run eight times faster than before on FireFox, faster than Elm, and about as fast as hand-written JavaScript, proving that it is your method of implementing Curry'ing in BS that is the problem. Remember that Elm doesn't have, and doesn't really need these notations. There are several differences: 1) BS does not use function wrappers with tagged arities but uses the function .length property to determine the arity on each invokation; it seems this is slow on current Firefox, 2) ) Elm doesn't need an arity check/currying function when there in only one function argument so doesn't wrap the functions or use the currying check function in this case, thus saves some time for single argument functions, and 3) (which turned out not to affect the speed in this case) Elm doesn't have true closures but normally just depends on immutability so as to be able to directly refer to and use captured free bindings; if one needs a closure (say to freeze a mutable loop variable in a Tail Call Optimized - TCO'd - loop), one just writes one themselves, with the ability to write an IIFE lifted in the code to where ever is best for minimum impact on performance. For this benchmark I didn't have to pay any attention to this. If you don't want to improve the performance of your Curry'ing functions on FireFox, I'll just drop it and let your users be sure to use the [@bs] notations if they want to generate fast code for (current) FireFox. The reason I am interested in Elm is that I want an easy-to-use programming environment and programming language that I can use to generate quick browser applications to demonstrate some advanced math concepts to my students, sometimes with a game-like interface to keep them interested. As these are each quite small projects, compilation speed doesn't really bother me much, but I do want to be able to reduce the file size for download/transfer, and it seems there are tools that will do that for me from Elm. Even a 3D graphics interface written in Elm is not impossible using the IArray library I mentioned in another post. I have never envisioned replacing Elm with BS, just augmenting some of the things that are difficult in Elm. Now, it seems more and more that Elm will be able to do the majority of the work, especially if I am able to help improve the execution speed, and I believe I now finally am able to narrow down the areas which need work. -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
