Benefits of Racket-on-Chez for laymen

[Gour]

Hello,

I'm interested to learn and use Racket for desktop apps and after reading about
the plan to use Chez Scheme as Racket's VM I wonder what are the implications
of this step for the end users?

By looking at this https://ecraven.github.io/r7rs-benchmarks/ benchmark it's
clear that Chez Scheme is very fast, if not the fastest Scheme implementation.
Now I wonder if Racket-on-Chez does mean that Racket's performance will improve
and/or one will be able to take advantage of Chez's feature to produce
stand-alone executables?

Does Racket-on-Chez mean one will get the best of both worlds, iow. have Chez's
performance, exectuables, multiple threads support etc. while still enjoying
Racket's ecosystem - package manager, batteries-included, programming
environment, excellent docs etc.

All these could make Racket even more attractive as 'geneal purpose programming
language'.

Otoh, I see that mflatt does contribute a lot to the Chez...


Sincerely,
Gour

--
Bewildered by the modes of material nature, the ignorant fully
engage themselves in material activities and become attached. But
the wise should not unsettle them, although these duties are inferior
due to the performers' lack of knowledge.

[Matthew Flatt]

At Wed, 13 Sep 2017 08:29:55 +0200, Gour wrote:
> I'm interested to learn and use Racket for desktop apps and after
> reading about the plan to use Chez Scheme as Racket's VM I wonder
> what are the implications of this step for the end users?
>

> Does Racket-on-Chez mean one will get the best of both worlds, iow.
> have Chez's performance, exectuables, multiple threads support etc.
> while still enjoying Racket's ecosystem - package manager,
> batteries-included, programming environment, excellent docs etc.

Yes, that's the goal. In the near term, the best-case scenario is that
existing Racket programs run on Chez Scheme and sometimes run faster
and/or in less memory.

The benefits within Racket's implementation are much greater in the
near term, since the new Racket layer is more maintainable and
adaptable, and that layer lives on a Chez Scheme base that is certainly
better than the part of the Racket that it replaces. Hopefully, this
internal restructuring will allow more people to contribute to Racket's
implementation, leading to a range of improvements for end users in the
long run.

> Otoh, I see that mflatt does contribute a lot to the Chez...

Only a few small things, and only recently.


Matthew

[Gour]

On Thu, 14 Sep 2017 05:53:59 -0600
Matthew Flatt <mfl...@cs.utah.edu> wrote:

> Yes, that's the goal. In the near term, the best-case scenario is that
> existing Racket programs run on Chez Scheme and sometimes run faster
> and/or in less memory.

Wonderful!

> The benefits within Racket's implementation are much greater in the
> near term, since the new Racket layer is more maintainable and
> adaptable, and that layer lives on a Chez Scheme base that is
> certainly better than the part of the Racket that it replaces.

You don't envision 'impedance mismatch' between the two?

> Hopefully, this internal restructuring will allow more people to
> contribute to Racket's implementation, leading to a range of
> improvements for end users in the long run.

Bright future for the Racket...

> Only a few small things, and only recently.

Humble, us usual. ;)


Sincerely,
Gour

--
Abandoning all attachment to the results of his activities,
ever satisfied and independent, he performs no fruitive action,
although engaged in all kinds of undertakings.

[David King]

From a fully layman and newbie perspective, I'm most interested in the possibility of actual threads that can run on more than one core. Is this a thing that will come for "free"?

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Robby Findler]

Racket already has two ways to do this: futures and threads. (There was a recent discussion on the mailing lists about futures.)

The guide has more information here: https://docs.racket-lang.org/guide/parallelism.html

Robby

[Philip McGrath]

futures and places, I think you mean

-Philip

> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.

[David King]

Racket already has two ways to do this: futures and threads. (There was a recent discussion on the mailing lists about futures.)

The guide has more information here: https://docs.racket-lang.org/guide/parallelism.html

It's true but threads aren't actually parallel, futures can use only limited fp-related operations, and places have much stronger restrictions than threaded code in most languages does.

[Robby Findler]

Whoops! Yes, thank you. 

Robby 

> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

[Robby Findler]

Ah. If that was the question, then I believe the answer is likely to be "no", but wouldn't presume to know for sure. 

Robby

[Sam Tobin-Hochstadt]

While we don't plan to change the semantics of threads or of futures,
Sarah Spall is working on implementing futures in the Chez-backed
version of the runtime in a way that will hopefully provide
parallelism for far more operations than Racket's current runtime
allows. However, it's still to early to report on any results of that
effort, which is ongoing.

Sam

[George Neuner]

On Fri, 15 Sep 2017 14:48:00 -0700, David King
<dk...@ketralnis.com> wrote:

>... and places have much stronger restrictions than threaded

>code in most languages does.

??? There are restrictions wrt shared data ... but AFAIK places have
no execution restrictions vs a [normal] serial program.

And place channels really are no more restrictive than are pipes
between processes.

George