Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Optimizing Guile Scheme

dthompson.us

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Optimizing Guile Scheme

#11

Post by sctb »

munificent wrote: post #9

I have such mixed feelings about dynamically typed languages. I've designed a whole pile of hobby programming languages, and dynamically typed languages are at least an order of magnitude simpler to design and for users to learn and start using. At the same time, they inevitably seem to lead to user stories like this where a user really does know exactly what types they're working with and wants the language to know…

I like dynamic languages too. But I don't like the idea of "optimization", and I would be super interested in a dynamic language that didn't attempt to divorce performance from correctness. The worst part about jumping through insane hoops to enchant the optimizer is that it can all go wrong with the tiniest change--a flag here, a different usage pattern there, a new version, etc., and suddenly your program doesn't do what you need it to, as though an operation taking 1000x longer is just a matter of degree.

Re: Optimizing Guile Scheme

#12

Post by eru »

atemerev wrote: post #8

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler. Common Lisp/SBCL is usually sufficiently smart. I know not everyone likes Common Lisp, but at least I would have tested it with something more performant that Guile, like Chicken Scheme (my favorite!), Chez Scheme, etc. I like Guile and its purpose as a universal scripting language. However, its performance issues are well…

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

Re: Optimizing Guile Scheme

#13

Post by medo-bear »

eru wrote: post #12
atemerev wrote: post #8

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler. Common Lisp/SBCL is usually sufficiently smart. I know not everyone likes Common Lisp, but at least I would have tested it with something more performant that Guile, like Chicken Scheme (my favorite!), Chez Scheme, etc. I like Guile and its purpose as a universal scripting language. However, its performance issues are well…

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

No

Re: Optimizing Guile Scheme

#14

Post by School-Cotton »

eru wrote: post #12
atemerev wrote: post #8

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler. Common Lisp/SBCL is usually sufficiently smart. I know not everyone likes Common Lisp, but at least I would have tested it with something more performant that Guile, like Chicken Scheme (my favorite!), Chez Scheme, etc. I like Guile and its purpose as a universal scripting language. However, its performance issues are well…

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

Extremely easy interop with native code is the main selling point of guile IMO. You just link in guile as a library and can have C code call scheme code and vice versa. Makes it great for any native program that needs an embedded scripting language (much like Lua). Does Racket support that use-case?

Re: Optimizing Guile Scheme

#16

Post by davexunit »

throwaway17_17 wrote: post #7

Solid blog overall and I think it is pitched at the right level of granularity for the topic. However, if I were offering criticism, the place I think more detail would be super interesting is the 'Please Inline' section. In particular, I would really be interested in a slightly more detailed description of the optimizer's algorithm for inlining. I think the "define_inlinable" macro is a great example of macro usage,…

A walkthrough of Guile's optimization passes and the inlining heuristics would be great. I've been meaning to do a "part two" here but you know how these things go.

Re: Optimizing Guile Scheme

#17

Post by munificent »

sctb wrote: post #11
munificent wrote: post #9

I have such mixed feelings about dynamically typed languages. I've designed a whole pile of hobby programming languages, and dynamically typed languages are at least an order of magnitude simpler to design and for users to learn and start using. At the same time, they inevitably seem to lead to user stories like this where a user really does know exactly what types they're working with and wants the language to know…

I like dynamic languages too. But I don't like the idea of "optimization", and I would be super interested in a dynamic language that didn't attempt to divorce performance from correctness. The worst part about jumping through insane hoops to enchant the optimizer is that it can all go wrong with the tiniest change--a flag here, a different usage pattern there, a new version, etc., and suddenly your program doesn't d…

I agree completely.

At the same time, no one wants their code to run 100x slower than it would in any typical statically typed language. Unoptimized dynamic languages are sloooooow.

Re: Optimizing Guile Scheme

#18

Post by davexunit »

atemerev wrote: post #8

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler. Common Lisp/SBCL is usually sufficiently smart. I know not everyone likes Common Lisp, but at least I would have tested it with something more performant that Guile, like Chicken Scheme (my favorite!), Chez Scheme, etc. I like Guile and its purpose as a universal scripting language. However, its performance issues are well…

Guile has come a long way in the past decade or so! I think your info is quite out of date. Guile's compiler performs a number of state of the art optimizations. It compiles to bytecode so native code compilers like Chez win the race, naturally. The JIT is pretty good, though! Native compilation is on the roadmap for Guile, but maybe somewhat surprisingly we're getting AOT compilation to WebAssembly first. https://spritely.institute/hoot/

Re: Optimizing Guile Scheme

#19

Post by tmtvl »

atemerev wrote: post #8

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler. Common Lisp/SBCL is usually sufficiently smart. I know not everyone likes Common Lisp, but at least I would have tested it with something more performant that Guile, like Chicken Scheme (my favorite!), Chez Scheme, etc. I like Guile and its purpose as a universal scripting language. However, its performance issues are well…

I switched from Guile to SBCL because I really like having things such as (declare (inline my-function)) and (declare (type Double-Float x y z)). Now if only it had case-lambda, named let, and a better deftype which can specify members of classes and/or structs.

Re: Optimizing Guile Scheme

#20

Post by mepian »

eru wrote: post #12
atemerev wrote: post #8

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler. Common Lisp/SBCL is usually sufficiently smart. I know not everyone likes Common Lisp, but at least I would have tested it with something more performant that Guile, like Chicken Scheme (my favorite!), Chez Scheme, etc. I like Guile and its purpose as a universal scripting language. However, its performance issues are well…

Isn't Racket the 'default' Scheme? (Even though it's no longer called Scheme.)

At this point it's a separate language from Scheme. I think Chez Scheme tends to be the "default" recommendation.
Post reply on HN