Also, the monotyped approach is easier to optimize, all else
equal. See qfox.nl/weblog/265 for testimony about this
(find "JIT mixed messages").
Is there a message where JS implementers and optimization-
dependent JS users can talk to each other?
Micro optimizations, even if drastically effective today, can be
unnecessary tomorrow. They can even be contra-productive
tomorrow, by encoding too much detail, thereby preventing
improved JS implementations from applying their optimizations.
In most cases, they obscure higher-level ideas and impede
code maintenance ("// don't touch this, efficiency at risk!").
Having a topic-specific list would allow optimizing JS coders
to raise such issues and their workarounds, giving JS implementers
a chance to automate the workarounds (preferably subsuming
them in generally applicable optimizations). It would also give
JS implementers a common forum for publishing best practices,
and gathering optimization research (engines could still compete
in selecting and implementing optimizations).
Optimizing JS is more difficult than optimizing other languages -
harder/impossible to analyze, no time to run several rounds
of advanced code transformations, etc. (*). Still, it would be
better to try and improve the implementations, instead of
adapting code too much to their current state. For instance,
the by-character string matching to reduce repeated tests in
that blog post is subsumed by standard pattern match
optimizations in functional languages.
Until such list is created, implementers and coders interested
in discussing the inner workings of optimizing JS engines
would be welcome to discuss (non-ES-standard-related)
topics on js-tools - the JS engine is the ultimate JS tool!-).
http://groups.google.com/group/js-tools/about
If such an implementation and optimization research list
for JS exists, please let me know (and in;-).
Claus
(*) One idea to work around this: implement optimizing
JS2JS compilers, from maintainable high-level JS to
efficiently executable LLJS. Then the optimizer could
take its time. In a way, minimizers follow this route
for code size optimization.
> Also, the monotyped approach is easier to optimize, all else
> equal. See http://qfox.nl/weblog/265 for testimony about this
> (find "JIT mixed messages").
Is there a message where JS implementers and optimization-
dependent JS users can talk to each other?
Micro optimizations, even if drastically effective today, can be
unnecessary tomorrow. They can even be contra-productive
tomorrow, by encoding too much detail, thereby preventing
improved JS implementations from applying their optimizations.
In most cases, they obscure higher-level ideas and impede
code maintenance ("// don't touch this, efficiency at risk!").
Having a topic-specific list would allow optimizing JS coders
to raise such issues and their workarounds, giving JS implementers
a chance to automate the workarounds (preferably subsuming
them in generally applicable optimizations). It would also give
JS implementers a common forum for publishing best practices,
and gathering optimization research (engines could still compete
in selecting and implementing optimizations).
Optimizing JS is more difficult than optimizing other languages -
harder/impossible to analyze, no time to run several rounds
of advanced code transformations, etc. (*). Still, it would be
better to try and improve the implementations, instead of
adapting code too much to their current state. For instance,
the by-character string matching to reduce repeated tests in
that blog post is subsumed by standard pattern match
optimizations in functional languages.
Until such list is created, implementers and coders interested
in discussing the inner workings of optimizing JS engines
would be welcome to discuss (non-ES-standard-related)
topics on js-tools - the JS engine is the ultimate JS tool!-).
http://groups.google.com/group/js-tools/about
If such an implementation and optimization research list
for JS exists, please let me know (and in;-).
Claus
(*) One idea to work around this: implement optimizing
JS2JS compilers, from maintainable high-level JS to
efficiently executable LLJS. Then the optimizer could
take its time. In a way, minimizers follow this route
for code size optimization.
Is there a message where JS implementers and optimization- dependent JS users can talk to each other?
Micro optimizations, even if drastically effective today, can be unnecessary tomorrow. They can even be contra-productive tomorrow, by encoding too much detail, thereby preventing improved JS implementations from applying their optimizations. In most cases, they obscure higher-level ideas and impede code maintenance ("// don't touch this, efficiency at risk!").
Having a topic-specific list would allow optimizing JS coders to raise such issues and their workarounds, giving JS implementers a chance to automate the workarounds (preferably subsuming them in generally applicable optimizations). It would also give JS implementers a common forum for publishing best practices, and gathering optimization research (engines could still compete in selecting and implementing optimizations).
Optimizing JS is more difficult than optimizing other languages - harder/impossible to analyze, no time to run several rounds of advanced code transformations, etc. (*). Still, it would be better to try and improve the implementations, instead of adapting code too much to their current state. For instance, the by-character string matching to reduce repeated tests in that blog post is subsumed by standard pattern match optimizations in functional languages.
Until such list is created, implementers and coders interested in discussing the inner workings of optimizing JS engines would be welcome to discuss (non-ES-standard-related) topics on js-tools - the JS engine is the ultimate JS tool!-).
If such an implementation and optimization research list for JS exists, please let me know (and in;-).
Claus
(*) One idea to work around this: implement optimizing JS2JS compilers, from maintainable high-level JS to efficiently executable LLJS. Then the optimizer could take its time. In a way, minimizers follow this route for code size optimization.
> Also, the monotyped approach is easier to optimize, all else > equal. See http://qfox.nl/weblog/265 for testimony about this > (find "JIT mixed messages"). Is there a message where JS implementers and optimization- dependent JS users can talk to each other? Micro optimizations, even if drastically effective today, can be unnecessary tomorrow. They can even be contra-productive tomorrow, by encoding too much detail, thereby preventing improved JS implementations from applying their optimizations. In most cases, they obscure higher-level ideas and impede code maintenance ("// don't touch this, efficiency at risk!"). Having a topic-specific list would allow optimizing JS coders to raise such issues and their workarounds, giving JS implementers a chance to automate the workarounds (preferably subsuming them in generally applicable optimizations). It would also give JS implementers a common forum for publishing best practices, and gathering optimization research (engines could still compete in selecting and implementing optimizations). Optimizing JS is more difficult than optimizing other languages - harder/impossible to analyze, no time to run several rounds of advanced code transformations, etc. (*). Still, it would be better to try and improve the implementations, instead of adapting code too much to their current state. For instance, the by-character string matching to reduce repeated tests in that blog post is subsumed by standard pattern match optimizations in functional languages. Until such list is created, implementers and coders interested in discussing the inner workings of optimizing JS engines would be welcome to discuss (non-ES-standard-related) topics on js-tools - the JS engine is the ultimate JS tool!-). http://groups.google.com/group/js-tools/about If such an implementation and optimization research list for JS exists, please let me know (and in;-). Claus (*) One idea to work around this: implement optimizing JS2JS compilers, from maintainable high-level JS to efficiently executable LLJS. Then the optimizer could take its time. In a way, minimizers follow this route for code size optimization.