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

51–60 of 82 posts

Re: Optimizing Guile Scheme

#51

Post by hayley-patton »

whartung wrote: post #32
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…

Part of the problem is that raw Scheme is spectacularly underspecified. It also doesn't help that Schemes like Guile are also interactive. The domain of an interactive language and a "compiled" language are quite different. Given the entirety of the program made available to the compiler all at once, there are high level derivations that can happen notably through flow analysis to let the compiler make better decisio…

> But do that in an interactive environment when the rug can be pulled out of any of the assumption the compiler made, and things get messy quite quickly.

https://bibliography.selflanguage.org/_static/dynamic-deopti...

Re: Optimizing Guile Scheme

#52

Post by shawn_w »

tmtvl wrote: post #19
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.

>named let

Serapeum has you covered: https://github.com/ruricolist/serapeum/blob/master/REFERENCE...

Re: Optimizing Guile Scheme

#53

Post by ducktective »

nouripenny wrote: post #47
erik_seaberg wrote: post #45

Earlier quoted context omitted.

I wish Common Lisp had integrated type declarations with TYPEP and CHECK-TYPE, instead of punting with "consequences are undefined if the value of the declared variable is not of the declared type," i.e., sucks to be you.

No doubt you know this, but Common Lisp's standardization gave leeway to implementations. So you could choose which implementation suits you better. Common Lisp is an umbrella for different Lisps to have some commonality. It was a process of negotiation, during a time when there were many design forks in the road, and diverse use-cases For example, type declarations can enable performance optimizations, compiletime t…

As someone who doesn't know much about types, do SBCL type declarations provide as good type-based development experience as OCaml and Rust?

And perhaps I wouldn't get your answer, I mean is there something fundamentally inadequate in the way SBCL declares types? I think there is a phrase for it in CS theory.

Re: Optimizing Guile Scheme

#54

Post by Y_Y »

eru wrote: post #40
tmtvl wrote: post #29

Earlier quoted context omitted.

I don't think there's a real 'default' Scheme, like Chez is probably the implementation which generates the fastest code, but if I'm not mistaken it only implements the R6RS spec, Guile is quite performant and supports both R6RS and R7RS Small, Chicken has a bunch of libraries (the 'eggs'), but I think it's R5RS (I may be wrong), and of course GNU/MIT Scheme is what you want to follow along with MIT publications work…

Thanks for the context! It's been a while since I did serious work in the Lisps. (I've moved on to the ML family.) > [...] GNU/MIT Scheme is what you want to follow along with MIT publications working in Scheme (like Structure and Interpretation of Computer Programs, Structure and Interpretation of Classical Mechanics, and The Art of the Propagator). Definitely, though I suspect if you need a language that's exactly…

In SICM they frequently make use of a kind of implicit applicative lifting (I can't remember what they call it) where you apply a vector-of-functions as if it were a function itself. In psuedo-Haskell:

    lift :: Vec (a->b) -> (a->Vec b)
    lift [] a = []
    lift f:fs = (f a):(lift fs $ a)
so that you can write natural-looking multidimensional physics expressions like

    ((fx fy fz) r)
without having to invoke macros or restructure the expression to please the compiler. I dearly wish you could do this in another scheme but so far I haven't found one. Iirc it's required for using the magnificent `scmutils` package too.

For example, `guile-scmutils`[0] says:

> Functionality not available in the port:

> Scheme extension to allow applying vectors/structures as procedures. For example rather than

    1 ]=> (pe ((up (literal-function 'x) (literal-function 'y)) 't))
    (up (x t) (y t))
> you must use

    guile> (pe ((lambda (t) (up ((literal-function 'x) t) ((literal-function 'y) t))) 't))
    (up (x t) (y t))
[0] https://www.cs.rochester.edu/~gildea/guile-scmutils/

Re: Optimizing Guile Scheme

#55

Post by pjmlp »

wbl wrote: post #33
tmtvl wrote: post #29

Earlier quoted context omitted.

I don't think there's a real 'default' Scheme, like Chez is probably the implementation which generates the fastest code, but if I'm not mistaken it only implements the R6RS spec, Guile is quite performant and supports both R6RS and R7RS Small, Chicken has a bunch of libraries (the 'eggs'), but I think it's R5RS (I may be wrong), and of course GNU/MIT Scheme is what you want to follow along with MIT publications work…

Racket is now built around Chez.

Which was a great idea, bootstraped languages always takes the usual "but you depend on XYZ" that haters always bring into the discussion.

Additionally they allow to prove a point.

For example, is writing compilers systems programming or not?

Re: Optimizing Guile Scheme

#56

Post by medo-bear »

ducktective wrote: post #53
nouripenny wrote: post #47

Earlier quoted context omitted.

No doubt you know this, but Common Lisp's standardization gave leeway to implementations. So you could choose which implementation suits you better. Common Lisp is an umbrella for different Lisps to have some commonality. It was a process of negotiation, during a time when there were many design forks in the road, and diverse use-cases For example, type declarations can enable performance optimizations, compiletime t…

As someone who doesn't know much about types, do SBCL type declarations provide as good type-based development experience as OCaml and Rust? And perhaps I wouldn't get your answer, I mean is there something fundamentally inadequate in the way SBCL declares types? I think there is a phrase for it in CS theory.

> As someone who doesn't know much about types, do SBCL type declarations provide as good type-based development experience as OCaml and Rust?

First of all, op was talking about strongly typed languages. Asking are they good as statically typed ones like Rust and OCaml is raising the goal posts quite a bit.

Second of all, SBCL can indeed have a subsection of its code expressed in OCaml-like static types, see

https://github.com/coalton-lang/coalton

Re: Optimizing Guile Scheme

#57

Post by masfoobar »

davexunit wrote: post #21
bitwize wrote: post #6

Earlier quoted context omitted.

The slogan I've proposed for the language is "Guile goes with everything." Because Guile was designed from the outset to run embedded or standalone, and to transpile other extension languages to Scheme or a Scheme-compatible representation, I think that fitting. See: https://knowyourmeme.com/memes/guiles-theme-goes-with-everyt...

I think the Guile community of yore would have no idea what Street Fighter was but now we should embrace it as long as Capcom doesn't get mad.

Originally, it was called GEL (GNU Extension Language) but was later renamed to GUILE.

https://wingolog.org/archives/2009/01/07/a-brief-history-of-...

There was a forum where Tom Lord, the creator of GEL talked about the early history from his perspective. Unfortunately I cannot remember where it is. Sadly, Tom Lord passed away in 2022.

Re: Optimizing Guile Scheme

#58

Post by 082349872349872 »

munificent wrote: post #17
sctb wrote: post #11

Earlier quoted context omitted.

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 .

Rpython and Graal (and what else?) provide JIT-for-free (or at least cheap).

Of course, this really only works for code that is (a) statically polymorphic but dynamically monomorphic, and (b) has hot loops, but qualitatively that conjunction does seem like it ought to cover a lot of low-hanging fruit.

Anyone have quantitative measures?

Re: Optimizing Guile Scheme

#60

Post by noelwelsh »

082349872349872 wrote: post #58
munificent wrote: post #17

Earlier quoted context omitted.

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 .

Rpython and Graal (and what else?) provide JIT-for-free (or at least cheap). Of course, this really only works for code that is (a) statically polymorphic but dynamically monomorphic, and (b) has hot loops, but qualitatively that conjunction does seem like it ought to cover a lot of low-hanging fruit. Anyone have quantitative measures?

There aren't many people looking at these JITs at the moment. Stefan Marr[1]'s group[2] is, I believe, the where most of the research is currently done. A recent paper[3] compares performance of interpreters in RPython and Graal. Their baseline performance is Java, and they achieve performance close to V8, which itself is about 2x slower than Java.

My summary is you can write fast interpreters + get JIT for free, but fast JIT for dynamic languages still means 2x slower than JIT for statically typed languages (and Java definitely leaves some performance on the table due to how it represents data).

[1]: https://stefan-marr.de/

[2]: https://research.kent.ac.uk/programming-languages-systems/

[3]: https://dl.acm.org/doi/10.1145/3622808

Post reply on HN