You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by "Interrante, John A (GE Research, US)" <Jo...@ge.com> on 2022/12/11 14:41:54 UTC
Enumeratum
The latest Scala Times newsletter mentioned an enumeration macro library. I looked at its README and was impressed at how many integrations it has, which also shows how large Scala's ecosystem is. Not saying we should use it in Daffodil, just saying FYI, this is a library worth knowing about.
https://github.com/lloydmeta/enumeratum
enumeratum<https://github.com/lloydmeta/enumeratum>
A type-safe, reflection-free, powerful enumeration implementation for Scala with exhaustive pattern match warnings and helpful integrations.
MIT license
<https://github.com/lloydmeta/enumeratum/blob/master/LICENSE>
scala native speed vs. JIT was: Re: Enumeratum
Posted by Mike Beckerle <mb...@apache.org>.
yes the JVM has the JIT, but the little benchmark I did is Tak, which is
just a pile of 3-arg function calls. (It's in our code base. Search for
Highly recursive, but never deeply. No allocation, no iteration. There's
nothing to optimize one would think - maybe branch prediction preferences.
My thought would have been that the best one can do is about as fast as
scala native would be, but scala native is obviously not generating
particularly tight code. I'll have to write Tak in C to get a baseline.
I don't want to bother with disassembling the output from scala native to
find out what is going on, but the notion that scala native is somehow
routinely faster is clearly more complex.
There is still one compelling reason for scala native which is program
startup time, which is very much faster. But Java's jlink (since Java 9) is
also addressing that, though it seems fairly hard to use.
On Thu, Dec 15, 2022 at 8:31 PM Adam Rosien <ad...@rosien.net> wrote:
> Re: scala native, wouldn't it *not* have the optimizing JIT when not on the
> JVM, therefore making it potentially slower if the (compiler-based)
> optimizer is inferior?
>
> On Thu, Dec 15, 2022 at 11:44 AM Interrante, John A (GE Research, US) <
> John.Interrante@ge.com> wrote:
>
> > The words "lots of integrations" comes from the library's README. As
> Adam
> > said, integrations seem to be Enumeratum add-on modules which help other
> > Scala ecosystem major players (Play framework, etc.) use Enumeratum with
> > their own software. Enumeratum itself supports Scala versions from 2.12
> to
> > 3.x along with Scala native and Scala js, so it can be used pretty
> > universally everywhere. I was simply remarking on the sheer number of
> > Enumeratum add-on modules showing how many Scala ecosystem players there
> > are some of which I hadn't known about.
> >
> > Regarding Scala native's speed on a micro-benchmark, that may be because
> > Java increases its speed by optimizing hot pieces of frequently run loops
> > like micro-benchmarks. If you really need native machine execution speed
> > along with good things like low energy consumption, memory/stack
> > protection, and functional computing, Rust is famous for providing all
> > these albeit with slow compilation speed and an ownership model which
> takes
> > time to understand.
> >
> > -----Original Message-----
> > From: Mike Beckerle <mb...@apache.org>
> > Sent: Thursday, December 15, 2022 2:03 PM
> > To: dev@daffodil.apache.org
> > Subject: EXT: Re: Enumeratum
> >
> > I guess I don't understand what it means for an enumerations library to
> > have "lots of integrations".
> > By this do you mean the versions of scala it supports, and the scala
> > native and scala js?
> >
> > I think these things are pretty easy to support for a small library with
> > no dependencies at all.
> >
> > re: Scala Native....
> >
> > Interesting tidbit about Scala native. I did a little micro-benchmark on
> > it, using our Tak scala code.
> >
> > It's substantially slower on scala native than on Java 19 openJDK JVM.
> >
> > One takeon is almost 2x as long on scala native as on standard java 19
> JVM.
> >
> > I found that somewhat surprising.
> >
> > On Sun, Dec 11, 2022 at 9:42 AM Interrante, John A (GE Research, US) <
> > John.Interrante@ge.com> wrote:
> >
> > > The latest Scala Times newsletter mentioned an enumeration macro
> library.
> > > I looked at its README and was impressed at how many integrations it
> > > has, which also shows how large Scala's ecosystem is. Not saying we
> > > should use it in Daffodil, just saying FYI, this is a library worth
> > knowing about.
> > >
> > > https://github.com/lloydmeta/enumeratum
> > > enumeratum<https://github.com/lloydmeta/enumeratum>
> > >
> > > A type-safe, reflection-free, powerful enumeration implementation for
> > > Scala with exhaustive pattern match warnings and helpful integrations.
> > >
> > > MIT license
> > > <https://github.com/lloydmeta/enumeratum/blob/master/LICENSE>
> > >
> >
>
Re: Enumeratum
Posted by Adam Rosien <ad...@rosien.net>.
Re: scala native, wouldn't it *not* have the optimizing JIT when not on the
JVM, therefore making it potentially slower if the (compiler-based)
optimizer is inferior?
On Thu, Dec 15, 2022 at 11:44 AM Interrante, John A (GE Research, US) <
John.Interrante@ge.com> wrote:
> The words "lots of integrations" comes from the library's README. As Adam
> said, integrations seem to be Enumeratum add-on modules which help other
> Scala ecosystem major players (Play framework, etc.) use Enumeratum with
> their own software. Enumeratum itself supports Scala versions from 2.12 to
> 3.x along with Scala native and Scala js, so it can be used pretty
> universally everywhere. I was simply remarking on the sheer number of
> Enumeratum add-on modules showing how many Scala ecosystem players there
> are some of which I hadn't known about.
>
> Regarding Scala native's speed on a micro-benchmark, that may be because
> Java increases its speed by optimizing hot pieces of frequently run loops
> like micro-benchmarks. If you really need native machine execution speed
> along with good things like low energy consumption, memory/stack
> protection, and functional computing, Rust is famous for providing all
> these albeit with slow compilation speed and an ownership model which takes
> time to understand.
>
> -----Original Message-----
> From: Mike Beckerle <mb...@apache.org>
> Sent: Thursday, December 15, 2022 2:03 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: Enumeratum
>
> I guess I don't understand what it means for an enumerations library to
> have "lots of integrations".
> By this do you mean the versions of scala it supports, and the scala
> native and scala js?
>
> I think these things are pretty easy to support for a small library with
> no dependencies at all.
>
> re: Scala Native....
>
> Interesting tidbit about Scala native. I did a little micro-benchmark on
> it, using our Tak scala code.
>
> It's substantially slower on scala native than on Java 19 openJDK JVM.
>
> One takeon is almost 2x as long on scala native as on standard java 19 JVM.
>
> I found that somewhat surprising.
>
> On Sun, Dec 11, 2022 at 9:42 AM Interrante, John A (GE Research, US) <
> John.Interrante@ge.com> wrote:
>
> > The latest Scala Times newsletter mentioned an enumeration macro library.
> > I looked at its README and was impressed at how many integrations it
> > has, which also shows how large Scala's ecosystem is. Not saying we
> > should use it in Daffodil, just saying FYI, this is a library worth
> knowing about.
> >
> > https://github.com/lloydmeta/enumeratum
> > enumeratum<https://github.com/lloydmeta/enumeratum>
> >
> > A type-safe, reflection-free, powerful enumeration implementation for
> > Scala with exhaustive pattern match warnings and helpful integrations.
> >
> > MIT license
> > <https://github.com/lloydmeta/enumeratum/blob/master/LICENSE>
> >
>
Enumeratum
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
The words "lots of integrations" comes from the library's README. As Adam said, integrations seem to be Enumeratum add-on modules which help other Scala ecosystem major players (Play framework, etc.) use Enumeratum with their own software. Enumeratum itself supports Scala versions from 2.12 to 3.x along with Scala native and Scala js, so it can be used pretty universally everywhere. I was simply remarking on the sheer number of Enumeratum add-on modules showing how many Scala ecosystem players there are some of which I hadn't known about.
Regarding Scala native's speed on a micro-benchmark, that may be because Java increases its speed by optimizing hot pieces of frequently run loops like micro-benchmarks. If you really need native machine execution speed along with good things like low energy consumption, memory/stack protection, and functional computing, Rust is famous for providing all these albeit with slow compilation speed and an ownership model which takes time to understand.
-----Original Message-----
From: Mike Beckerle <mb...@apache.org>
Sent: Thursday, December 15, 2022 2:03 PM
To: dev@daffodil.apache.org
Subject: EXT: Re: Enumeratum
I guess I don't understand what it means for an enumerations library to have "lots of integrations".
By this do you mean the versions of scala it supports, and the scala native and scala js?
I think these things are pretty easy to support for a small library with no dependencies at all.
re: Scala Native....
Interesting tidbit about Scala native. I did a little micro-benchmark on it, using our Tak scala code.
It's substantially slower on scala native than on Java 19 openJDK JVM.
One takeon is almost 2x as long on scala native as on standard java 19 JVM.
I found that somewhat surprising.
On Sun, Dec 11, 2022 at 9:42 AM Interrante, John A (GE Research, US) < John.Interrante@ge.com> wrote:
> The latest Scala Times newsletter mentioned an enumeration macro library.
> I looked at its README and was impressed at how many integrations it
> has, which also shows how large Scala's ecosystem is. Not saying we
> should use it in Daffodil, just saying FYI, this is a library worth knowing about.
>
> https://github.com/lloydmeta/enumeratum
> enumeratum<https://github.com/lloydmeta/enumeratum>
>
> A type-safe, reflection-free, powerful enumeration implementation for
> Scala with exhaustive pattern match warnings and helpful integrations.
>
> MIT license
> <https://github.com/lloydmeta/enumeratum/blob/master/LICENSE>
>
Re: Enumeratum
Posted by Adam Rosien <ad...@rosien.net>.
For "integrations", it means the enumerations library has support for use
in other libraries like cats, json libraries, HTTP libraries, testing, ORM,
etc., so the user doesn't have to bridge enum support themselves.
On Thu, Dec 15, 2022 at 11:03 AM Mike Beckerle <mb...@apache.org> wrote:
> I guess I don't understand what it means for an enumerations library to
> have "lots of integrations".
> By this do you mean the versions of scala it supports, and the scala native
> and scala js?
>
> I think these things are pretty easy to support for a small library with no
> dependencies at all.
>
> re: Scala Native....
>
> Interesting tidbit about Scala native. I did a little micro-benchmark on
> it, using our Tak scala code.
>
> It's substantially slower on scala native than on Java 19 openJDK JVM.
>
> One takeon is almost 2x as long on scala native as on standard java 19 JVM.
>
> I found that somewhat surprising.
>
> On Sun, Dec 11, 2022 at 9:42 AM Interrante, John A (GE Research, US) <
> John.Interrante@ge.com> wrote:
>
> > The latest Scala Times newsletter mentioned an enumeration macro library.
> > I looked at its README and was impressed at how many integrations it has,
> > which also shows how large Scala's ecosystem is. Not saying we should
> use
> > it in Daffodil, just saying FYI, this is a library worth knowing about.
> >
> > https://github.com/lloydmeta/enumeratum
> > enumeratum<https://github.com/lloydmeta/enumeratum>
> >
> > A type-safe, reflection-free, powerful enumeration implementation for
> > Scala with exhaustive pattern match warnings and helpful integrations.
> >
> > MIT license
> > <https://github.com/lloydmeta/enumeratum/blob/master/LICENSE>
> >
>
Re: Enumeratum
Posted by Mike Beckerle <mb...@apache.org>.
I guess I don't understand what it means for an enumerations library to
have "lots of integrations".
By this do you mean the versions of scala it supports, and the scala native
and scala js?
I think these things are pretty easy to support for a small library with no
dependencies at all.
re: Scala Native....
Interesting tidbit about Scala native. I did a little micro-benchmark on
it, using our Tak scala code.
It's substantially slower on scala native than on Java 19 openJDK JVM.
One takeon is almost 2x as long on scala native as on standard java 19 JVM.
I found that somewhat surprising.
On Sun, Dec 11, 2022 at 9:42 AM Interrante, John A (GE Research, US) <
John.Interrante@ge.com> wrote:
> The latest Scala Times newsletter mentioned an enumeration macro library.
> I looked at its README and was impressed at how many integrations it has,
> which also shows how large Scala's ecosystem is. Not saying we should use
> it in Daffodil, just saying FYI, this is a library worth knowing about.
>
> https://github.com/lloydmeta/enumeratum
> enumeratum<https://github.com/lloydmeta/enumeratum>
>
> A type-safe, reflection-free, powerful enumeration implementation for
> Scala with exhaustive pattern match warnings and helpful integrations.
>
> MIT license
> <https://github.com/lloydmeta/enumeratum/blob/master/LICENSE>
>