Optimizing Guile Scheme

I have such mixed feelings about dynamically typed languages. I&#x27;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.<p>At the same time, they inevitably seem to lead to user stories like this where a user really does know exactly what types they&#x27;re working with and wants the language to know that too (for performance or correctness), and they end up jumping through all sorts of insane hoops to get the optimizer to do exactly what they want.

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 &#x27;Please Inline&#x27; section. In particular, I would really be interested in a slightly more detailed description of the optimizer&#x27;s algorithm for inlining. I think the &quot;define_inlinable&quot; macro is a great example of macro usage, but it is clearly a way to circumvent the inliner&#x27;s apparent short comings. I would like to be able to understand what heuristic the optimizer is using to see if there is a sensible default function construction style&#x2F;idiom that is more appealing to the optimizer for inlining. However, I am reminded of the inlining discussion in Chandler Carruth&#x27;s talk (Understanding Compiler Optimization) from a few years ago where he discusses how obscure and seemingly arbitrary, in general, inlining heuristics and their optimization passes are in practice. [1]<p>1 - <a href="https:&#x2F;&#x2F;youtu.be&#x2F;FnGCDLhaxKU?si=J3MhvJ-BmX5SG2N6&amp;t=1550" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;FnGCDLhaxKU?si=J3MhvJ-BmX5SG2N6&amp;t=1550</a>

If you want to read just an enormous amount of well-written bloggage about optimizing Guile Scheme, this is the spot: <a href="https:&#x2F;&#x2F;wingolog.org" rel="nofollow">https:&#x2F;&#x2F;wingolog.org</a><p>Andy Wingo is the maintainer and I get a kick out of everything he posts.

These sorts of optimizations can and should be handled by a (sufficiently smart (tm)) compiler.<p>Common Lisp&#x2F;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.<p>I like Guile and its purpose as a universal scripting language. However, its performance issues are well known. Even compared to other scripting-first languages (Lua, Perl, Python etc).

Great overview on how to approach improving code performance, without going down the usual route of rewriting into something else.

The guile source-&gt;source Optimizer is such a nice tool to see what is going on. Especially when writing macros. I really recommend Kent Dybvig&#x27;s &quot;the macro writer&#x27;s bill of rights&quot; to see how useful it can be.

I prefer Common Lisp with SBCL and Lem, but this is good too.<p>On SICP, Guile badly needs a module for the picture language from the book (and srfi-203 + srfi-216).

The monomorphic vs polymorphic argument is an interesting one. I think that you could explicitly get unboxing if you used something like CLOS style multimethods to dispatch based on the type, so that (add &lt;float&gt; &lt;float&gt;) would dispatch to the function that uses fadd on those operands. I never realized that you could use this kind functionality, multimethods or free monad interpreters, to write in-code optimizations that are conveniently abstracted away in actual code usage.<p>Edit: nevermind, that&#x27;s also dynamic dispatch. You&#x27;d have to add static dispatch via macros or some external transpilation step.

Makes me happy when I see Guile is alive and going.

The full numeric tower sounds like a great idea. But in retrospect you almost never want uint32 silently converting to bignum, or ending up with a low precision float.<p>Has anyone had a positive experience?

As soon as I saw the title, I thought of the streetfighter character, but this was actually an interesting read on a programming language, I had never heard of before

You probably shouldn’t do those things. The point of a high level language is to not have to think about such details. If you can’t get the performance you need, you should use a different tool, instead of trying to circumvent implicit limitations.