javascript output optimization.

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
well I've got them all done, for the life of me I can't get anything in
the default package to overwrite the default classes haxe provides,
hence why I have to:
  rm -rf haxe/std
  ln -s my/std haxe/std

But then i do the same with the compiler too, and the IDE tbh - kinda
hacked out my own "works for me" setup lol

Nathan

[hidden email] wrote:

> surely you can supply us with native javascript arrays as part of a
> haXelib targeted at javascript, I don't see how they need or should
> replace the std library, but be more an addon library that could be used
> when optimization was needed, like say sugar.   Maybe I am missing the
> point but if you just want a different interface and variant base
> classes so you can create faster code then just create a haXelib?
>
> On 28 Nov 2010, at 22:08, Nathan wrote:
>
>> Nicolas Cannasse wrote:
>>> Le 28/11/2010 12:53, Nathan a écrit :
>>>> JS has been pretty much ignored as a target, it's like a pre-alpha
>>>> "well
>>>> it works" target.
>>> Instead of bashing haXe .js output, you should describe much more
>>> precisely how the JS output can be made better, and detail why such
>>> changes are important for JS developers.
>>
>> Well, here's an outline of one tiny issue out of many.. but before I
>> do, I'm not knocking you Nicolas, or haxe directly, but , well we both
>> know the js support ain't great.
>>
>>> a) the code generated in methods is pretty much the same that one
>>> would write in plain JS, but since we go through a compiler it can be
>>> automatically optimized
>>
>> The native functionality provided by javascript engines isn't exposed
>> by haxe, instead haxe exposes custom functionality which matches it,
>> for instance let's go with something simple, Array.map() - haxe
>> doesn't expose this, it instead implements List and List.map(). Let's
>> test it with 3 lines of haxe:
>>
>> 1:  var x = new List<Int>();
>> 2:  for(i in 0...1000000) x.add(i);
>> 3:  var y = x.map( function(a) { return a/2; });
>>
>> compiles to a 500 line js, but we can ignore that for now, on to the
>> times!
>>
>> line 2: 2355ms
>> line 3: 2160ms
>>
>> and now the js version:
>>
>> 1:  var z = [];
>> 2:  while(i++ < 1000000) z.push(i);
>> 3:  var zy = z.map(function(a) {return a / 2;});
>>
>> line 2: 85ms
>> line 3: 177ms
>>
>> So, with haxe you've got a 4-5 second jam on the event loop, and thus
>> a 5 second jam of the UI.
>>
>> Or one could use "the great lambda" on an array and take advantage of
>> at least the native structure..
>>
>> line 2: 91ms
>> line 3: 1964ms
>>
>> Only a 2 second jam
>>
>> So I guess one could start trying to make clever maps which detect and
>> use the native functionality in compiled code, but then you see many
>> of the interfaces and methods are mismatched, for instance Array.map()
>> takes closures with three params (element,index,array), whereas haxe
>> defines a map() which takes closure(element) and mapi which takes
>> closure(index,element). Haxe has a foreach which is something like an
>> Array.every and Array.forEach in js is something like .iter() in haxe,
>> but then .iter uses iterators of course rather than just the for
>> construct, and so it continues.
>>
>> The problem is that the std/*.hx do not expose the core functionality
>> of the runtime, and instead use much (as you can see) slower userland
>> code, or have mismatched functionality, or simply doesn't expose it -
>> it's the interfaces that are wrong and that need to change, but then
>> that's a problem for the other targets - a mismatch.
>>
>> So, there's one little illustration - I'd guess, if you can address
>> that simple 'map' case, then the rest can be worked at till the js
>> target is supported properly.
>>
>> As you know, I've given it a go, and succeeded (perhaps not in
>> everybodies eyes ;), but it meant replacing std/ with a
>> supports-only-js std lib, and there are still some minor issues
>> outstanding, global contexts etc as you know.
>>
>> Not much point discussing a whole host of things, so will leave it there,
>>
>> Best,
>>
>> Nathan
>>
>>> b) using high-level constructs such as enums will enable the compiler
>>> to do smart optimizations that the developer might not have done itself
>>> This is the whole story of programming languages evolution - or else
>>> everybody would still be coding in ASM/C
>>> Nicoals
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
In reply to this post by jlm@justinfront.net
Specific code do not "compose" with the rest of the ecosystem..

Arrays are general data structure.
General algorithms you can use everywhere are based on those general data structure.
If you introduce new data structure you have to rewrite a lot + do some data transformation between optimized and generic unoptimized code.

I think a good solution (if possible) would idealy not introduce several standard libraries.

On Sun, Nov 28, 2010 at 11:25 PM, [hidden email] [via Haxe] <[hidden email]> wrote:
Its like I use native flash xml parsing because it's simpler and  
faster for me but if I wanted cross platform code I would use the  
standard haXe xml.
Standard libraries are for compatibility, if you need targeted library  
then it should atleast start as a haXelib.

On 28 Nov 2010, at 22:19, [hidden email] wrote:

> surely you can supply us with native javascript arrays as part of a  
> haXelib targeted at javascript, I don't see how they need or should  
> replace the std library, but be more an addon library that could be  
> used when optimization was needed, like say sugar.   Maybe I am  
> missing the point but if you just want a different interface and  
> variant base classes so you can create faster code then just create  
> a haXelib?
>
> On 28 Nov 2010, at 22:08, Nathan wrote:
>
>> Nicolas Cannasse wrote:
>>> Le 28/11/2010 12:53, Nathan a écrit :
>>>> JS has been pretty much ignored as a target, it's like a pre-
>>>> alpha "well
>>>> it works" target.
>>> Instead of bashing haXe .js output, you should describe much more  
>>> precisely how the JS output can be made better, and detail why  
>>> such changes are important for JS developers.
>>
>> Well, here's an outline of one tiny issue out of many.. but before  
>> I do, I'm not knocking you Nicolas, or haxe directly, but , well we  
>> both know the js support ain't great.
>>
>>> a) the code generated in methods is pretty much the same that one  
>>> would write in plain JS, but since we go through a compiler it can  
>>> be automatically optimized
>>
>> The native functionality provided by javascript engines isn't  
>> exposed by haxe, instead haxe exposes custom functionality which  
>> matches it, for instance let's go with something simple,  
>> Array.map() - haxe doesn't expose this, it instead implements List  
>> and List.map(). Let's test it with 3 lines of haxe:
>>
>> 1:  var x = new List<Int>();
>> 2:  for(i in 0...1000000) x.add(i);
>> 3:  var y = x.map( function(a) { return a/2; });
>>
>> compiles to a 500 line js, but we can ignore that for now, on to  
>> the times!
>>
>> line 2: 2355ms
>> line 3: 2160ms
>>
>> and now the js version:
>>
>> 1:  var z = [];
>> 2:  while(i++ < 1000000) z.push(i);
>> 3:  var zy = z.map(function(a) {return a / 2;});
>>
>> line 2: 85ms
>> line 3: 177ms
>>
>> So, with haxe you've got a 4-5 second jam on the event loop, and  
>> thus a 5 second jam of the UI.
>>
>> Or one could use "the great lambda" on an array and take advantage  
>> of at least the native structure..
>>
>> line 2: 91ms
>> line 3: 1964ms
>>
>> Only a 2 second jam
>>
>> So I guess one could start trying to make clever maps which detect  
>> and use the native functionality in compiled code, but then you see  
>> many of the interfaces and methods are mismatched, for instance  
>> Array.map() takes closures with three params (element,index,array),  
>> whereas haxe defines a map() which takes closure(element) and mapi  
>> which takes closure(index,element). Haxe has a foreach which is  
>> something like an Array.every and Array.forEach in js is something  
>> like .iter() in haxe, but then .iter uses iterators of course  
>> rather than just the for construct, and so it continues.
>>
>> The problem is that the std/*.hx do not expose the core  
>> functionality of the runtime, and instead use much (as you can see)  
>> slower userland code, or have mismatched functionality, or simply  
>> doesn't expose it - it's the interfaces that are wrong and that  
>> need to change, but then that's a problem for the other targets - a  
>> mismatch.
>>
>> So, there's one little illustration - I'd guess, if you can address  
>> that simple 'map' case, then the rest can be worked at till the js  
>> target is supported properly.
>>
>> As you know, I've given it a go, and succeeded (perhaps not in  
>> everybodies eyes ;), but it meant replacing std/ with a supports-
>> only-js std lib, and there are still some minor issues outstanding,  
>> global contexts etc as you know.
>>
>> Not much point discussing a whole host of things, so will leave it  
>> there,
>>
>> Best,
>>
>> Nathan
>>
>>> b) using high-level constructs such as enums will enable the  
>>> compiler to do smart optimizations that the developer might not  
>>> have done itself
>>> This is the whole story of programming languages evolution - or  
>>> else everybody would still be coding in ASM/C
>>> Nicoals
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5782704.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 06 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
In reply to this post by jlm@justinfront.net
(!= substitution)

On Sun, Nov 28, 2010 at 11:30 PM, Stephane Le Dorze <[hidden email]> wrote:
Specific code do not "compose" with the rest of the ecosystem..

Arrays are general data structure.
General algorithms you can use everywhere are based on those general data structure.
If you introduce new data structure you have to rewrite a lot + do some data transformation between optimized and generic unoptimized code.

I think a good solution (if possible) would idealy not introduce several standard libraries.

On Sun, Nov 28, 2010 at 11:25 PM, [hidden email] [via Haxe] <[hidden email]> wrote:
Its like I use native flash xml parsing because it's simpler and  
faster for me but if I wanted cross platform code I would use the  
standard haXe xml.
Standard libraries are for compatibility, if you need targeted library  
then it should atleast start as a haXelib.

On 28 Nov 2010, at 22:19, [hidden email] wrote:

> surely you can supply us with native javascript arrays as part of a  
> haXelib targeted at javascript, I don't see how they need or should  
> replace the std library, but be more an addon library that could be  
> used when optimization was needed, like say sugar.   Maybe I am  
> missing the point but if you just want a different interface and  
> variant base classes so you can create faster code then just create  
> a haXelib?
>
> On 28 Nov 2010, at 22:08, Nathan wrote:
>
>> Nicolas Cannasse wrote:
>>> Le 28/11/2010 12:53, Nathan a écrit :
>>>> JS has been pretty much ignored as a target, it's like a pre-
>>>> alpha "well
>>>> it works" target.
>>> Instead of bashing haXe .js output, you should describe much more  
>>> precisely how the JS output can be made better, and detail why  
>>> such changes are important for JS developers.
>>
>> Well, here's an outline of one tiny issue out of many.. but before  
>> I do, I'm not knocking you Nicolas, or haxe directly, but , well we  
>> both know the js support ain't great.
>>
>>> a) the code generated in methods is pretty much the same that one  
>>> would write in plain JS, but since we go through a compiler it can  
>>> be automatically optimized
>>
>> The native functionality provided by javascript engines isn't  
>> exposed by haxe, instead haxe exposes custom functionality which  
>> matches it, for instance let's go with something simple,  
>> Array.map() - haxe doesn't expose this, it instead implements List  
>> and List.map(). Let's test it with 3 lines of haxe:
>>
>> 1:  var x = new List<Int>();
>> 2:  for(i in 0...1000000) x.add(i);
>> 3:  var y = x.map( function(a) { return a/2; });
>>
>> compiles to a 500 line js, but we can ignore that for now, on to  
>> the times!
>>
>> line 2: 2355ms
>> line 3: 2160ms
>>
>> and now the js version:
>>
>> 1:  var z = [];
>> 2:  while(i++ < 1000000) z.push(i);
>> 3:  var zy = z.map(function(a) {return a / 2;});
>>
>> line 2: 85ms
>> line 3: 177ms
>>
>> So, with haxe you've got a 4-5 second jam on the event loop, and  
>> thus a 5 second jam of the UI.
>>
>> Or one could use "the great lambda" on an array and take advantage  
>> of at least the native structure..
>>
>> line 2: 91ms
>> line 3: 1964ms
>>
>> Only a 2 second jam
>>
>> So I guess one could start trying to make clever maps which detect  
>> and use the native functionality in compiled code, but then you see  
>> many of the interfaces and methods are mismatched, for instance  
>> Array.map() takes closures with three params (element,index,array),  
>> whereas haxe defines a map() which takes closure(element) and mapi  
>> which takes closure(index,element). Haxe has a foreach which is  
>> something like an Array.every and Array.forEach in js is something  
>> like .iter() in haxe, but then .iter uses iterators of course  
>> rather than just the for construct, and so it continues.
>>
>> The problem is that the std/*.hx do not expose the core  
>> functionality of the runtime, and instead use much (as you can see)  
>> slower userland code, or have mismatched functionality, or simply  
>> doesn't expose it - it's the interfaces that are wrong and that  
>> need to change, but then that's a problem for the other targets - a  
>> mismatch.
>>
>> So, there's one little illustration - I'd guess, if you can address  
>> that simple 'map' case, then the rest can be worked at till the js  
>> target is supported properly.
>>
>> As you know, I've given it a go, and succeeded (perhaps not in  
>> everybodies eyes ;), but it meant replacing std/ with a supports-
>> only-js std lib, and there are still some minor issues outstanding,  
>> global contexts etc as you know.
>>
>> Not much point discussing a whole host of things, so will leave it  
>> there,
>>
>> Best,
>>
>> Nathan
>>
>>> b) using high-level constructs such as enums will enable the  
>>> compiler to do smart optimizations that the developer might not  
>>> have done itself
>>> This is the whole story of programming languages evolution - or  
>>> else everybody would still be coding in ASM/C
>>> Nicoals
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5782704.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 06 08  76 70 15





--
Stéphane Le Dorze

Tel: +33 (0) 06 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Cauê W.
In reply to this post by Nathan
nathan, I really don't think your examples are very valid.

No-one writing performance critical code will use haxe's standard Lambdas for that, and if you still would like to use Lambdas in a performance-critical code (not very recommended), a custom inlined lambda would perform much better than js' native one.

I don't think this hunt for every little bit of performance is very necessary, and if you profile well, the bottlenecks are very easily identified and taken care of - haxe offers many ways to get native performance where you need it.

2010/11/28 Nathan <[hidden email]>
well I've got them all done, for the life of me I can't get anything in the default package to overwrite the default classes haxe provides, hence why I have to:
 rm -rf haxe/std
 ln -s my/std haxe/std

But then i do the same with the compiler too, and the IDE tbh - kinda hacked out my own "works for me" setup lol

Nathan


[hidden email] wrote:
surely you can supply us with native javascript arrays as part of a haXelib targeted at javascript, I don't see how they need or should replace the std library, but be more an addon library that could be used when optimization was needed, like say sugar.   Maybe I am missing the point but if you just want a different interface and variant base classes so you can create faster code then just create a haXelib?

On 28 Nov 2010, at 22:08, Nathan wrote:

Nicolas Cannasse wrote:
Le 28/11/2010 12:53, Nathan a écrit :
JS has been pretty much ignored as a target, it's like a pre-alpha "well
it works" target.
Instead of bashing haXe .js output, you should describe much more precisely how the JS output can be made better, and detail why such changes are important for JS developers.

Well, here's an outline of one tiny issue out of many.. but before I do, I'm not knocking you Nicolas, or haxe directly, but , well we both know the js support ain't great.

a) the code generated in methods is pretty much the same that one would write in plain JS, but since we go through a compiler it can be automatically optimized

The native functionality provided by javascript engines isn't exposed by haxe, instead haxe exposes custom functionality which matches it, for instance let's go with something simple, Array.map() - haxe doesn't expose this, it instead implements List and List.map(). Let's test it with 3 lines of haxe:

1:  var x = new List<Int>();
2:  for(i in 0...1000000) x.add(i);
3:  var y = x.map( function(a) { return a/2; });

compiles to a 500 line js, but we can ignore that for now, on to the times!

line 2: 2355ms
line 3: 2160ms

and now the js version:

1:  var z = [];
2:  while(i++ < 1000000) z.push(i);
3:  var zy = z.map(function(a) {return a / 2;});

line 2: 85ms
line 3: 177ms

So, with haxe you've got a 4-5 second jam on the event loop, and thus a 5 second jam of the UI.

Or one could use "the great lambda" on an array and take advantage of at least the native structure..

line 2: 91ms
line 3: 1964ms

Only a 2 second jam

So I guess one could start trying to make clever maps which detect and use the native functionality in compiled code, but then you see many of the interfaces and methods are mismatched, for instance Array.map() takes closures with three params (element,index,array), whereas haxe defines a map() which takes closure(element) and mapi which takes closure(index,element). Haxe has a foreach which is something like an Array.every and Array.forEach in js is something like .iter() in haxe, but then .iter uses iterators of course rather than just the for construct, and so it continues.

The problem is that the std/*.hx do not expose the core functionality of the runtime, and instead use much (as you can see) slower userland code, or have mismatched functionality, or simply doesn't expose it - it's the interfaces that are wrong and that need to change, but then that's a problem for the other targets - a mismatch.

So, there's one little illustration - I'd guess, if you can address that simple 'map' case, then the rest can be worked at till the js target is supported properly.

As you know, I've given it a go, and succeeded (perhaps not in everybodies eyes ;), but it meant replacing std/ with a supports-only-js std lib, and there are still some minor issues outstanding, global contexts etc as you know.

Not much point discussing a whole host of things, so will leave it there,

Best,

Nathan

b) using high-level constructs such as enums will enable the compiler to do smart optimizations that the developer might not have done itself
This is the whole story of programming languages evolution - or else everybody would still be coding in ASM/C
Nicoals


--
haXe - an open source web programming language
http://haxe.org





--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
In reply to this post by John A. De Goes
John A. De Goes wrote:
> Indeed, the use of types can actually allow more efficient code generation (dead code elimination, function inlining, etc.). Working at a higher level of abstraction sometimes allows higher performance.

Aye, but you know you need the basics there first, and that's only half
the problem, the interface mismatch and lack of object is a bigger
problem, then compiler output, then lack of a global context, then lack
of a prototype (afaik can't be fixed, total incompat here) then the
minor cleanup on things like regex mismatch issues (regex pattern
syntax, let alone RegExp vs EReg).

> In any case, I do agree that the code generator for the JS target can be improved. There are several distinct areas that can be improved:
>
> 1. Generate more natural JavaScript code, which eliminates unnecessary braces and parentheses.

yup, had a look at this but it may need to be an second run cleanup thing.

> 2. Generate smaller JavaScript code. For example, there are many tricks that can be used to very efficiently construct class hierarchies. The current approach assigns each prototype, which takes up a lot of kbs.

indeed go for a x.prototype = {
  __proto__: class.thisextents.prototype,
  methodFoo: function(x,t) {
    // blah
  },
  ...
}

approach, possibly even leveraging Object.defineProperties for
getter/setter and readonly members.

> 3. Generate faster JavaScript code. For example, not wrapping a code block inside a function when no variables are captured.

aye, again that's nice but minor compared to the interface mismatch
issues and using userland types rather than native types.

> 4. Eliminating dead code, factoring out the standard library, splitting generated code by packages or in other ways.
>
>  Finally, one might add "runtime class/package loading", but that's a more general feature which could be used in several other targets as well, and is significantly more complex.
>
> Currently, my company sponsors Franco on (4), but that's just a small part of the overall puzzle. We need a JavaScript champion who can own (1) - (3). Someone who knows how to write efficient, fast JavaScript code, and isn't afraid to dig into the compiler to change the code generator.

Cool, Franco's a great guy - work with him myself on a couple of bits :)

> Any volunteers? Nathan, I know you can do this. :-)

Was that even a question lol - don't know if I've got the time to be
honest, or more to the point, if haxe wasn't written in ocaml I'd have
done 1-4 and a lot more besides already, find it rather tricky hacking
on ocaml compared to, well every other language I've ever used, I even
converted all of the haxe compiler to js using soem tooling then started
to clean it up - but.. that was a nasty job which made me question
myself "wtf am I doing".

In honestly-really terms, haxe needs to get js support fast, otherwise
somebody else will pull out a js specific compiler with all the features
of haxe, and it'll be to js what haxe was to flash 4-5 years ago - it's
out of respect for NC and the haxe community that I keep rearing my head
and raising these issues every now and then, in a nudge nudge here's
you're big break, I'll even help, kind of way - but it ain't really
happening, and ocaml pretty much prevents the community from doing it.
Still, fingers crossed, might happen - haxe might have it's day (a
jquery sized multimillion defacto tool kind of day), we'll see.

Best,

Nathan

> Regards,
>
> John A. De Goes
> Twitter: @jdegoes
> LinkedIn: http://linkedin.com/in/jdegoes
>
> On Nov 28, 2010, at 12:55 PM, Nicolas Cannasse wrote:
>
>> Le 28/11/2010 12:53, Nathan a écrit :
>>> JS has been pretty much ignored as a target, it's like a pre-alpha "well
>>> it works" target.
>> [...]
>>
>> I think you're being overly unfair on haXe/JS support.
>>
>> I'm the first one to admit that it requires more work, and I've already advanced on some of the things we have been discussing in the past.
>>
>> For instance today I have committed the --macro compiler parameter implementation which will enable macro-controlled compiler configuration. A few uses cases can be :
>>
>> - manage excluded classes, allowing for instance to exclude interfaces from being generated
>> - allow custom .js splitting (per package, or using your own rules)
>> - ... and much more
>>
>> I have also talked with Franco about ways to avoid putting things in the global scope.
>>
>> Instead of bashing haXe .js output, you should describe much more precisely how the JS output can be made better, and detail why such changes are important for JS developers.
>>
>> Also, I don't agree with your claim that haXe high-level approach is doomed to be less optimized, since
>>
>> a) the code generated in methods is pretty much the same that one would write in plain JS, but since we go through a compiler it can be automatically optimized
>>
>> b) using high-level constructs such as enums will enable the compiler to do smart optimizations that the developer might not have done itself
>>
>> This is the whole story of programming languages evolution - or else everybody would still be coding in ASM/C
>>
>> Nicoals
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
In reply to this post by Cauê W.
Cauê Waneck wrote:
> nathan, I really don't think your examples are very valid.
>
> No-one writing performance critical code will use haxe's standard Lambdas
> for that, and if you still would like to use Lambdas in a
> performance-critical code (not very recommended), a custom inlined lambda
> would perform much better than js' native one.

you've got to be joking? you think any userland code can perform better
than c optimized runtime provided native functionality?

> I don't think this hunt for every little bit of performance is very
> necessary, and if you profile well, the bottlenecks are very easily
> identified and taken care of - haxe offers many ways to get native
> performance where you need it.

Nobodies hunting for "little bits of performance", well I'm certainly
not, I'm talking about entire /really basic/ classes and types
completely missing, mismatched functionality and about 50 missing native
methods that cannot be implemented in userland to get within even 5x the
performance of the native methods, we're talking ms vs seconds here, on
a fast run event loop that blocks till the next cycle - it's not shaving
off a millisecond, it's making the code actually usable for anything
heavier than a basic script. And that's just one of the sets of issues.

Remove all of std/flash/*, mismatch all the core classes, slow down
performance to x times slower, would the rest of the haxe community
stand for that?

> 2010/11/28 Nathan <[hidden email]>
>
>> well I've got them all done, for the life of me I can't get anything in the
>> default package to overwrite the default classes haxe provides, hence why I
>> have to:
>>  rm -rf haxe/std
>>  ln -s my/std haxe/std
>>
>> But then i do the same with the compiler too, and the IDE tbh - kinda
>> hacked out my own "works for me" setup lol
>>
>> Nathan
>>
>>
>> [hidden email] wrote:
>>
>>> surely you can supply us with native javascript arrays as part of a
>>> haXelib targeted at javascript, I don't see how they need or should replace
>>> the std library, but be more an addon library that could be used when
>>> optimization was needed, like say sugar.   Maybe I am missing the point but
>>> if you just want a different interface and variant base classes so you can
>>> create faster code then just create a haXelib?
>>>
>>> On 28 Nov 2010, at 22:08, Nathan wrote:
>>>
>>>  Nicolas Cannasse wrote:
>>>>> Le 28/11/2010 12:53, Nathan a écrit :
>>>>>
>>>>>> JS has been pretty much ignored as a target, it's like a pre-alpha
>>>>>> "well
>>>>>> it works" target.
>>>>>>
>>>>> Instead of bashing haXe .js output, you should describe much more
>>>>> precisely how the JS output can be made better, and detail why such changes
>>>>> are important for JS developers.
>>>>>
>>>> Well, here's an outline of one tiny issue out of many.. but before I do,
>>>> I'm not knocking you Nicolas, or haxe directly, but , well we both know the
>>>> js support ain't great.
>>>>
>>>>  a) the code generated in methods is pretty much the same that one would
>>>>> write in plain JS, but since we go through a compiler it can be
>>>>> automatically optimized
>>>>>
>>>> The native functionality provided by javascript engines isn't exposed by
>>>> haxe, instead haxe exposes custom functionality which matches it, for
>>>> instance let's go with something simple, Array.map() - haxe doesn't expose
>>>> this, it instead implements List and List.map(). Let's test it with 3 lines
>>>> of haxe:
>>>>
>>>> 1:  var x = new List<Int>();
>>>> 2:  for(i in 0...1000000) x.add(i);
>>>> 3:  var y = x.map( function(a) { return a/2; });
>>>>
>>>> compiles to a 500 line js, but we can ignore that for now, on to the
>>>> times!
>>>>
>>>> line 2: 2355ms
>>>> line 3: 2160ms
>>>>
>>>> and now the js version:
>>>>
>>>> 1:  var z = [];
>>>> 2:  while(i++ < 1000000) z.push(i);
>>>> 3:  var zy = z.map(function(a) {return a / 2;});
>>>>
>>>> line 2: 85ms
>>>> line 3: 177ms
>>>>
>>>> So, with haxe you've got a 4-5 second jam on the event loop, and thus a 5
>>>> second jam of the UI.
>>>>
>>>> Or one could use "the great lambda" on an array and take advantage of at
>>>> least the native structure..
>>>>
>>>> line 2: 91ms
>>>> line 3: 1964ms
>>>>
>>>> Only a 2 second jam
>>>>
>>>> So I guess one could start trying to make clever maps which detect and
>>>> use the native functionality in compiled code, but then you see many of the
>>>> interfaces and methods are mismatched, for instance Array.map() takes
>>>> closures with three params (element,index,array), whereas haxe defines a
>>>> map() which takes closure(element) and mapi which takes
>>>> closure(index,element). Haxe has a foreach which is something like an
>>>> Array.every and Array.forEach in js is something like .iter() in haxe, but
>>>> then .iter uses iterators of course rather than just the for construct, and
>>>> so it continues.
>>>>
>>>> The problem is that the std/*.hx do not expose the core functionality of
>>>> the runtime, and instead use much (as you can see) slower userland code, or
>>>> have mismatched functionality, or simply doesn't expose it - it's the
>>>> interfaces that are wrong and that need to change, but then that's a problem
>>>> for the other targets - a mismatch.
>>>>
>>>> So, there's one little illustration - I'd guess, if you can address that
>>>> simple 'map' case, then the rest can be worked at till the js target is
>>>> supported properly.
>>>>
>>>> As you know, I've given it a go, and succeeded (perhaps not in
>>>> everybodies eyes ;), but it meant replacing std/ with a supports-only-js std
>>>> lib, and there are still some minor issues outstanding, global contexts etc
>>>> as you know.
>>>>
>>>> Not much point discussing a whole host of things, so will leave it there,
>>>>
>>>> Best,
>>>>
>>>> Nathan
>>>>
>>>>  b) using high-level constructs such as enums will enable the compiler to
>>>>> do smart optimizations that the developer might not have done itself
>>>>> This is the whole story of programming languages evolution - or else
>>>>> everybody would still be coding in ASM/C
>>>>> Nicoals
>>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>
>>>
>>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
In reply to this post by sledorze
sledorze wrote:

> Specific code do not "compose" with the rest of the ecosystem..
>
> Arrays are general data structure.
> General algorithms you can use everywhere are based on those general data
> structure.
> If you introduce new data structure you have to rewrite a lot + do some data
> transformation between optimized and generic unoptimized code.
>
> I think a good solution (if possible) would idealy not introduce several
> standard libraries.

exactly, it's anti-haxe-ethos, but it's the only "it really will work"
approach, if there were 6 haxes, all with a shared with a core syntax,
and each one augmented the target language perfectly, then this would be
  a community of several hundred thousand users, and haxe, would be
pretty much the fastest moving language on the planet - that's negating
the ocaml learning barrier of course.

How many of the community actually use the target anywhere features? how
many of you actually can? (I guess 3-5 max, tony, hugh, nc a couple of
others maybe), everybody else - had much luck getting your haxe/flash
uses flash classes app to work on php or js recently?

regards,

nathan

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Dion Amago
> How many of the community actually use the target anywhere features? how
> many of you actually can? (I guess 3-5 max, tony, hugh, nc a couple of
> others maybe), everybody else - had much luck getting your haxe/flash uses
> flash classes app to work on php or js recently?

http://dionamago.net/?p=410

Multiple targets are crucial for my project.  Flash + JS means a game
can target all clients (computers + smartphones).

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Philipp Klose-2
In reply to this post by danielku15
I really recommend UglifyJS (https://github.com/mishoo/UglifyJS), it
works very well for haXe generated JavaScript.

On 28.11.2010 02:20, danielku15 wrote:
> Additionally you can use code optimizers/minimizers like Google Closure
> Compiler, JsMin or Yahoo Javascript Compressor. I'm using the Google Closure
> Compiler to optimize the code which removes unneeded elements,  dead code
> and simplifies local variable names. (and a lot more)
>    

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
In reply to this post by Nathan
I am currently doing that.. and I think in the near future, a lot will do..

On Mon, Nov 29, 2010 at 12:00 AM, Nathan [via Haxe] <[hidden email]> wrote:
sledorze wrote:

> Specific code do not "compose" with the rest of the ecosystem..
>
> Arrays are general data structure.
> General algorithms you can use everywhere are based on those general data
> structure.
> If you introduce new data structure you have to rewrite a lot + do some data
> transformation between optimized and generic unoptimized code.
>
> I think a good solution (if possible) would idealy not introduce several
> standard libraries.
exactly, it's anti-haxe-ethos, but it's the only "it really will work"
approach, if there were 6 haxes, all with a shared with a core syntax,
and each one augmented the target language perfectly, then this would be
  a community of several hundred thousand users, and haxe, would be
pretty much the fastest moving language on the planet - that's negating
the ocaml learning barrier of course.

How many of the community actually use the target anywhere features? how
many of you actually can? (I guess 3-5 max, tony, hugh, nc a couple of
others maybe), everybody else - had much luck getting your haxe/flash
uses flash classes app to work on php or js recently?

regards,

nathan

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5782782.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 06 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

jlm@justinfront.net
In reply to this post by Nathan
> How many of the community actually use the target anywhere features?  
> how many of you actually can? (I guess 3-5 max, tony, hugh, nc a  
> couple of others maybe), everybody else - had much luck getting your  
> haxe/flash uses flash classes app to work on php or js recently?

I would have a go at a haxe game tomorrow in javascript, but I would  
not consider swapping out the std library in a hurry it's just does  
not seem maintainable approach, but I would welcome haxelib with  
'ArrayJ' in it, that was well documented, also something cross  
platform that helps with alpha.  I would use different view code for  
any haxe javascript but I guess some of the code could be 'anywhere'.  
My opinion is that your workflow of swapping out the standard library  
is actually useless from the haXe community perspective, if it works  
for you that's great but it does not really contribute in the way that  
maybe you aim, I would be far happier to see a haXelib that achieves  
some of your goals than hacking my whole install.



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Heinz Hölzer-2
In reply to this post by Philipp Klose-2
Am 29.11.2010 00:45, schrieb Philipp Klose:
> I really recommend UglifyJS (https://github.com/mishoo/UglifyJS), it
> works very well for haXe generated JavaScript.
>
wow, fantastic tool, thx.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
In reply to this post by jlm@justinfront.net
[hidden email] wrote:
> I would be far  happier to see a haXelib that achieves some of your
> goals than hacking  my whole install.

snap

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
In reply to this post by Nathan
I can understand you,

I am now benchmarking and optimizing my code using FF.

Doing so, I can ask myself if I am not going to reimplement what should have been in a std just for the sake of optimizing my code for JS and at the same time, without branching all my logic code..

I think we're sitting between generic or specialized datastructures.

On one side, having generic ones would prevent knowing too much about them but having them compiled to idiomatic browser code.
The sort of ds where you have a bunch of algorithms availables, but no implementation knowledge.

On the other side, you have well defined ("down to the metal") specialized data structures but completely loose "performance portability".
 
So where haxe sits?
My analysis is that it's selling point is more on genericity but its Std is more on specialization (flash?).


I am new to Haxe, I like it, it solve a lot of problems, even if there's some stuff I don't like and would love seeing this change (*put here more ML features*), they're minor compared to the advantages.

I was not aware that the JS problems were so fundamentals before this week.
Now I wonder if I made the right choice as I don't know the VISION (I hope to have done the right one because the others would make me cry.. ).

So, what's the end goal, what's the VISION? (not the road)

Stephane
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nicolas Cannasse
Le 29/11/2010 11:08, sledorze a écrit :
> So, what's the end goal, what's the VISION? (not the road)
>
> Stephane

The vision is to have haXe being a perfect candidate for people who want
to do serious things in JavaScript, because it brings you a more
highlevel language with a powerful type system.

So far the JS code generator has been focused on compatibility, in the
sense that we wanted to make sure that all haXe code runs correctly in JS.

We can now focus on output code quality and performances, depending on
the community feedback and whishlist. I'm confident that there is
nothing haXe can't do, that's just a matter of making the right choices
and giving priorities.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
Glad to hear this :) everything starts with motivation.
I think there's pretty a lot of people willing to contribute which is fine..

Now, what is the process?
I know processes could be counter productive if they're not light, but I think there's minimal needs:

How and where is defined the whishlist based on the community feedback?
How to we measure code quality? (do we put quality tracking in the build system?)

Stephane

On Mon, Nov 29, 2010 at 2:15 PM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 29/11/2010 11:08, sledorze a écrit :
> So, what's the end goal, what's the VISION? (not the road)
>
> Stephane

The vision is to have haXe being a perfect candidate for people who want
to do serious things in JavaScript, because it brings you a more
highlevel language with a powerful type system.

So far the JS code generator has been focused on compatibility, in the
sense that we wanted to make sure that all haXe code runs correctly in JS.

We can now focus on output code quality and performances, depending on
the community feedback and whishlist. I'm confident that there is
nothing haXe can't do, that's just a matter of making the right choices
and giving priorities.

Nicolas

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5784285.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 06 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Lars Madson

I would be interested in a list of plateform specific optimisations.
For exemple I didn't know using Array over List in Javascript would make such a huge difference.

If everyone start to use optimisation knowledge we can more easily get some people to implement it at a compiler level.

Laurent

Le 29/11/2010 14:27, sledorze a écrit :
Glad to hear this :) everything starts with motivation.
I think there's pretty a lot of people willing to contribute which is fine..

Now, what is the process?
I know processes could be counter productive if they're not light, but I think there's minimal needs:

How and where is defined the whishlist based on the community feedback?
How to we measure code quality? (do we put quality tracking in the build system?)

Stephane

On Mon, Nov 29, 2010 at 2:15 PM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 29/11/2010 11:08, sledorze a écrit :
> So, what's the end goal, what's the VISION? (not the road)
>
> Stephane

The vision is to have haXe being a perfect candidate for people who want
to do serious things in JavaScript, because it brings you a more
highlevel language with a powerful type system.

So far the JS code generator has been focused on compatibility, in the
sense that we wanted to make sure that all haXe code runs correctly in JS.

We can now focus on output code quality and performances, depending on
the community feedback and whishlist. I'm confident that there is
nothing haXe can't do, that's just a matter of making the right choices
and giving priorities.

Nicolas

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5784285.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 06 08  76 70 15




View this message in context: Re: javascript output optimization.
Sent from the Haxe mailing list archive at Nabble.com.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Simon Richardson
Exactly, giving a list of what to use and where to use over existing code (as said), so as to aggregate knowledge. It should be noted that these should be tested in terms of performance and consequences.


On 29 Nov 2010, at 13:48, Laurent Kappler wrote:


I would be interested in a list of plateform specific optimisations.
For exemple I didn't know using Array over List in Javascript would make such a huge difference.

If everyone start to use optimisation knowledge we can more easily get some people to implement it at a compiler level.

Laurent

Le 29/11/2010 14:27, sledorze a écrit :
Glad to hear this :) everything starts with motivation.
I think there's pretty a lot of people willing to contribute which is fine..

Now, what is the process?
I know processes could be counter productive if they're not light, but I think there's minimal needs:

How and where is defined the whishlist based on the community feedback?
How to we measure code quality? (do we put quality tracking in the build system?)

Stephane

On Mon, Nov 29, 2010 at 2:15 PM, Nicolas Cannasse [via Haxe] <<a moz-do-not-send="true" href="x-msg://91/user/SendEmail.jtp?type=node&amp;node=5784309&amp;i=0" target="_top" rel="nofollow">[hidden email]> wrote:
Le 29/11/2010 11:08, sledorze a écrit :
> So, what's the end goal, what's the VISION? (not the road)
>
> Stephane

The vision is to have haXe being a perfect candidate for people who want
to do serious things in JavaScript, because it brings you a more
highlevel language with a powerful type system.

So far the JS code generator has been focused on compatibility, in the
sense that we wanted to make sure that all haXe code runs correctly in JS.

We can now focus on output code quality and performances, depending on
the community feedback and whishlist. I'm confident that there is
nothing haXe can't do, that's just a matter of making the right choices
and giving priorities.

Nicolas

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5784285.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 06 08  76 70 15




View this message in context: Re: javascript output optimization.
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
In reply to this post by Lars Madson
Laurent Kappler wrote:
> I would be interested in a list of plateform specific optimisations.
> For exemple I didn't know using Array over List in Javascript would make
> such a huge difference.

Ideally you shouldn't have to know that using Array over List would make
a big difference, if you do know that, and start making target specific
optimizations, then it's going to be counter productive for your code on
other targets / or get you in to a big mess of #target switching.

The main speed difference will be gained by coding to interfaces, rather
than implementations, so not using array instead of list, but rather
still using list, and having list backed by several target specific
implementations.


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
In reply to this post by Simon Richardson
Hence the need for agreeing on a process.
Otherwise, this would end up in only an endless discussion ^_^
Can we put this stuff on the wiki?
1234