Hacker News Reader

Comment by wduquette | Hacker News Reader

I first experimented with Lisp back in the mid-80’s, and have returned to it time and again—not as a language for serious projects, but just as a way of learning new techniques and new ways to think about writing software. I’ve tried using Racket on a number of occasions going back to way before it was called that, and something about the software just puts me off. Perhaps I could get past that if I stuck with it, but I just can’t see myself writing a large project using Racket.

View on HN

I liked it many years ago but when I noticed how slow and heavy my code was I left it. It manages to be slower than Python. Perhaps the Chez Scheme rewrite helped with that but now if I need a Lisp I have Common Lisp which is super fast and lightweight enough.

It's usually faster than Python for numeric stuff, and has a similar speed for strings. See for example https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But if you run the code inside the default IDE call DrRacket, you must go to the menu Language>Choose_Language... then click "Show_Details" and disable "Debugging".

With debugging enabled, you get nicer error messages, but it blocks a lot of optimizations and the program get slow.

See for example

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

These are small benchmarks, so don’t over-generalize from this data point alone, but Racket absolutely crushes Python in terms of speed and goes speedily enough against other popular performance-focused languages:

https://lambdaland.org/posts/2023-12-20_functional_langauge_...

https://lambdaland.org/posts/2024-09-27_threaded_interpreter...

Matthew Flatt, the Racket lead, says that Racket’s performance should be fairly comparable to Java, much faster than Python, slower than Julia/Rust/etc. That’s been a helpful model for me: if Java is fast enough, Racket will do fine.

Nice examples! With a few tricks, I made the Racket program x5 faster. I think you tried to use the simplest program, so I tried to add as few cheats as possible. I added a happy path for fixnums and keep the slow path in case the iterations gets too big:

  (define (count-collatz n [cnt 1])
    (if (fixnum? n)
        (cond
          [(= n 1) cnt]
          #;[(zero? (unsafe-fxremainder n 2)) (count-collatz (unsafe-fxquotient n 2) (+ 1 cnt))]
          [(zero? (fxand n 1)) (count-collatz (unsafe-fxquotient n 2) (+ 1 cnt))]
          [else (count-collatz (+ (* 3 n) 1) (+ 1 cnt))])
        (cond
          [(= n 1) cnt]
          [(even? n) (count-collatz (/ n 2) (+ 1 cnt))]
          [else (count-collatz (+ (* 3 n) 1) (+ 1 cnt))])))

My program has two versions, the version with `fxand` is slightly faster than the versions with `fxremainder`. I have to used two `unsafe-` functions, but a smart enough optimizer should have fixed them. So I'm adding this example to my wishlist.

I think it would be very hard for the optimizer would be to replace `/` with `quotient`, but the rest look possible.

I wonder how, given that anything that brings Python and performance together, usually means it is actually C code, or similar, as PyPy is seldom reached for.

Raket is compiled, thus maybe not the right build parameters?

when you say "software" do you mean the language features or the tooling?

The tooling.

Reply on news.ycombinator.com