Discussion:
[gambit-list] --enable-single-host is sufficient for general use
Bradley Lucier
2017-08-16 16:57:10 UTC
Permalink
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
Marc Feeley
2017-08-16 18:04:11 UTC
Permalink
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
Post by Bradley Lucier
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
mikel evins
2017-08-16 18:13:18 UTC
Permalink
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
Marc Feeley
2017-08-17 02:11:05 UTC
Permalink
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
Post by mikel evins
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
mikel evins
2017-08-17 02:13:23 UTC
Permalink
Post by Marc Feeley
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
Adam
2017-09-17 10:21:50 UTC
Permalink
Post by Marc Feeley
Post by Marc Feeley
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?
Sonny To
2017-09-17 16:36:48 UTC
Permalink
Have you considered running the output through google closure compiler for
the tree shaking? thats what clojurescript does
Post by Adam
Post by Marc Feeley
Post by Marc Feeley
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Adam
2017-09-18 07:10:23 UTC
Permalink
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
Post by Sonny To
Have you considered running the output through google closure compiler for
the tree shaking? thats what clojurescript does
Post by Adam
Post by Marc Feeley
Post by Marc Feeley
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
James Baker
2017-09-18 09:06:00 UTC
Permalink
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
Post by Adam
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
Post by Sonny To
Have you considered running the output through google closure compiler
for the tree shaking? thats what clojurescript does
Post by Adam
Post by Marc Feeley
Post by Marc Feeley
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc Feeley
2017-09-18 11:23:23 UTC
Permalink
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
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
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
Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
Post by Marc Feeley
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc
James Baker
2017-09-18 20:36:46 UTC
Permalink
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
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
Post by James Baker
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.
Post by James Baker
Cheers,
James
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.
Post by James Baker
So the whole way input code maps to JS code is beyond what JS code
shaker's abilities.
Post by James Baker
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.
Post by James Baker
What about you give it a try and let us know here?
Adam
Have you considered running the output through google closure compiler
for the tree shaking? thats what clojurescript does
Post by James Baker
Post by Marc Feeley
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.
Post by James Baker
Nice!
Thanks,
--me
What's new with respect to the Javascript output now?
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc
Marc Feeley
2017-09-18 20:40:14 UTC
Permalink
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
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
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
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
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
Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
Post by Marc Feeley
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
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
_______________________________________________
Gambit-list mailing list
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc
Hendrik Boom
2017-08-17 14:16:50 UTC
Permalink
Post by Marc Feeley
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
mikel evins
2017-08-17 14:35:05 UTC
Permalink
Post by Hendrik Boom
Post by Marc Feeley
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".
Bradley Lucier
2017-08-18 20:12:58 UTC
Permalink
I added another column and another sentence to explain my position.

Brad
Post by Marc Feeley
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
Post by Bradley Lucier
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
https://secure-web.cisco.com/1Wh2bepdwIt-fsOZGLdKlI7Mo38odEGixIKAvYXbCyALLzG8ezz76CZfebJkNIe-Gm7BzqIy5QOlrpEB4dbdVJXQbhhcTmchO_xUiYa5eML7g2YRYmLWWe69idT_hMxzmtX8GsNZv3nNgw_3JnyNvEzVvosod96B7XI1SON8PNaLd5eeGX0M6xFE7K2fUNqsvpdtTudvQHSL1KH8YSRKvbhocwCQpg2qJg37n6xq2V0Oh2BrXCLtQLEN63AkH9pdkMXxgBEnjRBgQv2N3NhMZ3SOxOR8WrJAFlR3c1m86jaX2BYtHld9BBgk9coEzLLY0Vfz7eg3rohTkQLJAeisRl3Tinh4zXaGqiQZ7Nd5-dc4/https%3A%2F%2Fwebmail.iro.umontreal.ca%2Fmailman%2Flistinfo%2Fgambit-list
Continue reading on narkive:
Loading...