There is a table at
http://www.math.purdue.edu/~lucier/gambit-optimization-comparison.html
benchmarking Gambit with various levels of optimization.
I would conclude that for general purposes, one doesn't need --enable-c-opt or --enable-gcc-opts when configuring.
Brad
Afficher les réponses par date
I read your data differently… the best time is with --enable-c-opt and --enable-gcc-opts together… no?
Note that this is with the gcc compiler. Have you tried with clang?
Also, could you check -O3 instead of -O2? Maybe that makes a bigger difference and should be the default for --enable-c-opt.
Marc
On Aug 16, 2017, at 12:57 PM, Bradley Lucier lucier@math.purdue.edu wrote:
There is a table at
http://www.math.purdue.edu/~lucier/gambit-optimization-comparison.html
benchmarking Gambit with various levels of optimization.
I would conclude that for general purposes, one doesn't need --enable-c-opt or --enable-gcc-opts when configuring.
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc,
I've been playing with the idea of retargeting my Bard implementation primarily at Javascript platforms. What's the present status of the JS target in Gambit? My main concerns are whether it remains an active area you're working on and whether it's reasonably convenient to compile a Gambit program to a fairly small JS output.
Thanks for your help,
--me
The JavaScript backend is being worked on actively this summer. It is in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Marc
On Aug 16, 2017, at 2:13 PM, mikel evins mevins@me.com wrote:
Marc,
I've been playing with the idea of retargeting my Bard implementation primarily at Javascript platforms. What's the present status of the JS target in Gambit? My main concerns are whether it remains an active area you're working on and whether it's reasonably convenient to compile a Gambit program to a fairly small JS output.
Thanks for your help,
--me
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
The JavaScript backend is being worked on actively this summer. It is in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca
wrote:
The JavaScript backend is being worked on actively this summer. It is
in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now?
Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
On Sun, Sep 17, 2017 at 6:21 AM Adam adam.mlmb@gmail.com wrote:
2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca
wrote:
The JavaScript backend is being worked on actively this summer. It is
in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now? _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Sonny,
Gambit has its own register of global variables, which it keeps in some JS object. An external JS code tree shaker would not be able to distinguish what can be removed and what cannot as they - as far as I am aware - not introspect JS structures, but instead just look for unused identifiers/functions and remove those. And also it would not be able to remove what's not used.
So the whole way input code maps to JS code is beyond what JS code shaker's abilities.
However maybe my understanding of your JS tree shaker is not correct and it's so incredibly smart that it can cut through also such intricate code.
What about you give it a try and let us know here?
Adam
2017-09-18 0:36 GMT+08:00 Sonny To son.c.to@gmail.com:
Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
On Sun, Sep 17, 2017 at 6:21 AM Adam adam.mlmb@gmail.com wrote:
2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca
wrote:
The JavaScript backend is being worked on actively this summer. It is
in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now? _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
I've tried Google Closure compiler previously on Gambit generated JS and it worked fine, it was a while ago and admittedly my scheme code wasn't doing anything overly complicated but still.
Cheers,
James
On Mon, Sep 18, 2017 at 5:10 PM, Adam adam.mlmb@gmail.com wrote:
Sonny,
Gambit has its own register of global variables, which it keeps in some JS object. An external JS code tree shaker would not be able to distinguish what can be removed and what cannot as they - as far as I am aware - not introspect JS structures, but instead just look for unused identifiers/functions and remove those. And also it would not be able to remove what's not used.
So the whole way input code maps to JS code is beyond what JS code shaker's abilities.
However maybe my understanding of your JS tree shaker is not correct and it's so incredibly smart that it can cut through also such intricate code.
What about you give it a try and let us know here?
Adam
2017-09-18 0:36 GMT+08:00 Sonny To son.c.to@gmail.com:
Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
On Sun, Sep 17, 2017 at 6:21 AM Adam adam.mlmb@gmail.com wrote:
2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca
wrote:
The JavaScript backend is being worked on actively this summer. It
is in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now? _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
I’m with Adam on this subject. It would take some very fancy analysis for the Google Closure compiler to remove the code that Gambit’s tree shaker removes. Gambit can do it because it has knowledge about the structure and semantics of the generated code.
So when you say “it worked fine” I assume you mean the output code runs fine, not that Google Closure did a good job at removing dead code. Some benchmarking would be useful here!
Marc
On Sep 18, 2017, at 5:06 AM, James Baker james@waveformdynamics.com.au wrote:
I've tried Google Closure compiler previously on Gambit generated JS and it worked fine, it was a while ago and admittedly my scheme code wasn't doing anything overly complicated but still.
Cheers,
James
On Mon, Sep 18, 2017 at 5:10 PM, Adam adam.mlmb@gmail.com wrote: Sonny,
Gambit has its own register of global variables, which it keeps in some JS object. An external JS code tree shaker would not be able to distinguish what can be removed and what cannot as they - as far as I am aware - not introspect JS structures, but instead just look for unused identifiers/functions and remove those. And also it would not be able to remove what's not used.
So the whole way input code maps to JS code is beyond what JS code shaker's abilities.
However maybe my understanding of your JS tree shaker is not correct and it's so incredibly smart that it can cut through also such intricate code.
What about you give it a try and let us know here?
Adam
2017-09-18 0:36 GMT+08:00 Sonny To son.c.to@gmail.com: Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
On Sun, Sep 17, 2017 at 6:21 AM Adam adam.mlmb@gmail.com wrote: 2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
The JavaScript backend is being worked on actively this summer. It is in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now? _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc
Well the code size shrank considerably and the code still ran as expected, thats all I recall. Keep in mind though that some of the optimisations done by closure are whitespace removal / string substitutions etc which are decidedly less complicated than global analysis and dead code removal. I really couldn't tell you which level (simple / advanced) of optimisations that I tried. I was simply curious to see if it would help reduce the payload size is all.
Cheers,
James
On Mon, Sep 18, 2017 at 9:23 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
I’m with Adam on this subject. It would take some very fancy analysis for the Google Closure compiler to remove the code that Gambit’s tree shaker removes. Gambit can do it because it has knowledge about the structure and semantics of the generated code.
So when you say “it worked fine” I assume you mean the output code runs fine, not that Google Closure did a good job at removing dead code. Some benchmarking would be useful here!
Marc
On Sep 18, 2017, at 5:06 AM, James Baker james@waveformdynamics.com.au
wrote:
I've tried Google Closure compiler previously on Gambit generated JS and
it worked fine, it was a while ago and admittedly my scheme code wasn't doing anything overly complicated but still.
Cheers,
James
On Mon, Sep 18, 2017 at 5:10 PM, Adam adam.mlmb@gmail.com wrote: Sonny,
Gambit has its own register of global variables, which it keeps in some
JS object. An external JS code tree shaker would not be able to distinguish what can be removed and what cannot as they - as far as I am aware - not introspect JS structures, but instead just look for unused identifiers/functions and remove those. And also it would not be able to remove what's not used.
So the whole way input code maps to JS code is beyond what JS code
shaker's abilities.
However maybe my understanding of your JS tree shaker is not correct and
it's so incredibly smart that it can cut through also such intricate code.
What about you give it a try and let us know here?
Adam
2017-09-18 0:36 GMT+08:00 Sonny To son.c.to@gmail.com: Have you considered running the output through google closure compiler
for the tree shaking? thats what clojurescript does
On Sun, Sep 17, 2017 at 6:21 AM Adam adam.mlmb@gmail.com wrote: 2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca
wrote:
The JavaScript backend is being worked on actively this summer. It is
in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now? _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc
OK, that makes sense. The code generated by the universal backend has long identifiers and plenty of whitespace so compression at that level will help a lot. Of course combining that with the tree shaker will give the best results.
Marc
On Sep 18, 2017, at 4:36 PM, James Baker james@waveformdynamics.com.au wrote:
Well the code size shrank considerably and the code still ran as expected, thats all I recall. Keep in mind though that some of the optimisations done by closure are whitespace removal / string substitutions etc which are decidedly less complicated than global analysis and dead code removal. I really couldn't tell you which level (simple / advanced) of optimisations that I tried. I was simply curious to see if it would help reduce the payload size is all.
Cheers,
James
On Mon, Sep 18, 2017 at 9:23 PM, Marc Feeley feeley@iro.umontreal.ca wrote: I’m with Adam on this subject. It would take some very fancy analysis for the Google Closure compiler to remove the code that Gambit’s tree shaker removes. Gambit can do it because it has knowledge about the structure and semantics of the generated code.
So when you say “it worked fine” I assume you mean the output code runs fine, not that Google Closure did a good job at removing dead code. Some benchmarking would be useful here!
Marc
On Sep 18, 2017, at 5:06 AM, James Baker james@waveformdynamics.com.au wrote:
I've tried Google Closure compiler previously on Gambit generated JS and it worked fine, it was a while ago and admittedly my scheme code wasn't doing anything overly complicated but still.
Cheers,
James
On Mon, Sep 18, 2017 at 5:10 PM, Adam adam.mlmb@gmail.com wrote: Sonny,
Gambit has its own register of global variables, which it keeps in some JS object. An external JS code tree shaker would not be able to distinguish what can be removed and what cannot as they - as far as I am aware - not introspect JS structures, but instead just look for unused identifiers/functions and remove those. And also it would not be able to remove what's not used.
So the whole way input code maps to JS code is beyond what JS code shaker's abilities.
However maybe my understanding of your JS tree shaker is not correct and it's so incredibly smart that it can cut through also such intricate code.
What about you give it a try and let us know here?
Adam
2017-09-18 0:36 GMT+08:00 Sonny To son.c.to@gmail.com: Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
On Sun, Sep 17, 2017 at 6:21 AM Adam adam.mlmb@gmail.com wrote: 2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
The JavaScript backend is being worked on actively this summer. It is in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now? _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc
On Wed, Aug 16, 2017 at 10:11:05PM -0400, Marc Feeley wrote:
Currently we are working on implementing a tree shaker to reduce the size of generated code.
First time I've heard the term "tree shaker". Last time I saw a tree shake was at night a few hears ago, when the tree I was walking under suddenly acquired a nimbus of water drops, and then a major branch fell off. If I had been a second later in walking by the tree, I would likely be dead.
For me it's a very vivid image.
-- hendrik
On Aug 17, 2017, at 9:16 AM, Hendrik Boom hendrik@topoi.pooq.com wrote:
On Wed, Aug 16, 2017 at 10:11:05PM -0400, Marc Feeley wrote:
Currently we are working on implementing a tree shaker to reduce the size of generated code.
First time I've heard the term "tree shaker". Last time I saw a tree shake was at night a few hears ago, when the tree I was walking under suddenly acquired a nimbus of water drops, and then a major branch fell off. If I had been a second later in walking by the tree, I would likely be dead.
For me it's a very vivid image.
It's kind of an old-fashioned terminology in the lisp world for procedures that try to determine the parts of the lisp that are not used at runtime. In some languages that's simple: you just don't link things that are not referenced. In lisps it's not so cut and dried, because programs can dynamically construct references to things, thus the metaphor of "shaking loose" things that are not "strongly attached".
I added another column and another sentence to explain my position.
Brad
On 08/16/2017 02:04 PM, Marc Feeley wrote:
I read your data differently… the best time is with --enable-c-opt and --enable-gcc-opts together… no?
Note that this is with the gcc compiler. Have you tried with clang?
Also, could you check -O3 instead of -O2? Maybe that makes a bigger difference and should be the default for --enable-c-opt.
Marc
On Aug 16, 2017, at 12:57 PM, Bradley Lucier lucier@math.purdue.edu wrote:
There is a table at
http://www.math.purdue.edu/~lucier/gambit-optimization-comparison.html
benchmarking Gambit with various levels of optimization.
I would conclude that for general purposes, one doesn't need --enable-c-opt or --enable-gcc-opts when configuring.
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://secure-web.cisco.com/1Wh2bepdwIt-fsOZGLdKlI7Mo38odEGixIKAvYXbCyALLzG...
-
Adam -
Bradley Lucier -
Hendrik Boom -
James Baker -
Marc Feeley -
mikel evins -
Sonny To