4 ms·

> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance Unfortunately they are not doing

> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain. Based on their most recent blog on the subject (https://blog.racket-lang.org/2019/01/racket-on-chez-status.html https://blog.racket-lang.org/2019/01/racket-on-chez-status.h...), the new backend is almost uniformly slower to load, takes up twice as much memory, takes more than twice as long to build, takes twice as long to compile Racket code, and the compiled code generally runs slower than it used to. (They expect that this last one will improve, but they have never indicated that they expect it to actually match or exceed the speed of code compiled with the old backend.) Also, the new back-end, by design, permanently removes support for the Racket C API. This trade-off is hard for me to understand. I don’t maintain Racket, so I don’t have any idea how much effort this will ultimately save those who do. But I do know that I the main thing holding me back from investing more development time in Racket is its poor performance compared to languages like PHP, Python or Go; and I have never seen explained, and can’t even imagine, what new features the maintainers will now be able to implement that would actually make Racket development more productive or enjoyable.

bjoli 8y ago
I think the smaller example Matthew Flatt used in a talk about the expander is a better example. From the old expander's conception (many many years ago) only 2 people commited any changes and one of those only committed smaller instrumentation changes. Since the rewrite (that was about 1.5 to 2x slower) less than a year ago 6 people had made commits. What one could hope for would be some chez scheme interoperability for the really speed demanding parts.
hajile 8y ago
The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance). http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-chez-status/pict.svg http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-c... According to them, fixing things takes much less time and is much easier to understand. For a system where lots of development is free, ease of understanding and fixing is extremely important. > But I do know that I the main thing holding me back from investing more development time in Racket is its poor performance compared to languages like PHP, Python or Go Racket is slower than Go because racket is dynamically typed, is a much higher-level language, and has to implement continuations. Racket is much faster than python or PHP. My big issue with racket is dev tools. DrRacket isn't very good IMO. They need to make a server that implements the Language Server Protocol with some additional hooks for more dynamic lisp stuff. At that point, devs can choose to use all kinds of actually good editors (sublime, VS Code, Vim, Emacs, IntelliJ, etc) for coding. They can even add the LSP to DrRacket and continue to use it. https://langserver.org/ https://langserver.org/
- hsitz 8y ago
  At least for people who want to use Emacs and Racket, it seems like this Emacs project provides the client/server kind of setup you're talking about. Or no?: https://www.greghendershott.com/2018/10/racket-mode.html https://www.greghendershott.com/2018/10/racket-mode.html
- soegaard 8y ago
  It's here: https://pkgs.racket-lang.org/package/racket-langserver https://pkgs.racket-lang.org/package/racket-langserver
- velcrovan 8y ago
  The new backed is overall faster according to that post. No, according to that post, the new back-end itself is massively slower than current Racket by every single measure shown. To reiterate, I’m talking about startup and load times, memory use, expand and compile times, and build times (i.e. time to compile the back-end itself). All slower. (Are you sure you're not referring to code compiled using the new back-end?) I grant that there is some benefit in that the longer compile times result in an improvement in some benchmarks, but that doesn’t negate that the new back-end is still slower than the old one by every measure. > Racket is much faster than python or PHP. This is funny because although you will find benchmarks out there to support this point, in my experience of writing and using Racket programs it has never hold up. Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution. I love the Racket language, and there are some DSLs like Pollen that do things I simply can’t imagine attempting anywhere else. But it’s for sure my last choice for speed, based on personal experience.
  - samth 8y ago
    > Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution. Can you point me to some examples of this? I haven't done AoC and so don't know where to find solutions posted to compare. It should be very rare for idiomatic python or php to be faster than idiomatic racket.
pjmlp 8y ago
First they need to make it correct, then they will make it faster. A major mistake in any porting is to do big refactoring changes during the process. As for why they are doing it, to remove the dependency in C, have a safer runtime that everyone in the Lisp/Scheme community would enjoy contributing to and have a bootstraped environment, removing the 2 language syndrome that plagues a few runtimes.

bjoli 8y ago

I think the smaller example Matthew Flatt used in a talk about the expander is a better example. From the old expander's conception (many many years ago) only 2 people commited any changes and one of those only committed smaller instrumentation changes. Since the rewrite (that was about 1.5 to 2x slower) less than a year ago 6 people had made commits. What one could hope for would be some chez scheme interoperability for the really speed demanding parts.

hajile 8y ago

The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance). http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-chez-status/pict.svg http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-c... According to them, fixing things takes much less time and is much easier to understand. For a system where lots of development is free, ease of understanding and fixing is extremely important. > But I do know that I the main thing holding me back from investing more development time in Racket is its poor performance compared to languages like PHP, Python or Go Racket is slower than Go because racket is dynamically typed, is a much higher-level language, and has to implement continuations. Racket is much faster than python or PHP. My big issue with racket is dev tools. DrRacket isn't very good IMO. They need to make a server that implements the Language Server Protocol with some additional hooks for more dynamic lisp stuff. At that point, devs can choose to use all kinds of actually good editors (sublime, VS Code, Vim, Emacs, IntelliJ, etc) for coding. They can even add the LSP to DrRacket and continue to use it. https://langserver.org/ https://langserver.org/

hsitz 8y ago
At least for people who want to use Emacs and Racket, it seems like this Emacs project provides the client/server kind of setup you're talking about. Or no?: https://www.greghendershott.com/2018/10/racket-mode.html https://www.greghendershott.com/2018/10/racket-mode.html
soegaard 8y ago
It's here: https://pkgs.racket-lang.org/package/racket-langserver https://pkgs.racket-lang.org/package/racket-langserver
velcrovan 8y ago
The new backed is overall faster according to that post. No, according to that post, the new back-end itself is massively slower than current Racket by every single measure shown. To reiterate, I’m talking about startup and load times, memory use, expand and compile times, and build times (i.e. time to compile the back-end itself). All slower. (Are you sure you're not referring to code compiled using the new back-end?) I grant that there is some benefit in that the longer compile times result in an improvement in some benchmarks, but that doesn’t negate that the new back-end is still slower than the old one by every measure. > Racket is much faster than python or PHP. This is funny because although you will find benchmarks out there to support this point, in my experience of writing and using Racket programs it has never hold up. Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution. I love the Racket language, and there are some DSLs like Pollen that do things I simply can’t imagine attempting anywhere else. But it’s for sure my last choice for speed, based on personal experience.
- samth 8y ago
  > Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution. Can you point me to some examples of this? I haven't done AoC and so don't know where to find solutions posted to compare. It should be very rare for idiomatic python or php to be faster than idiomatic racket.

pjmlp 8y ago

First they need to make it correct, then they will make it faster. A major mistake in any porting is to do big refactoring changes during the process. As for why they are doing it, to remove the dependency in C, have a safer runtime that everyone in the Lisp/Scheme community would enjoy contributing to and have a bootstraped environment, removing the 2 language syndrome that plagues a few runtimes.