RE: Nested singletons and Java

> -----Original Message-----
> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>
> It means adding static forwarding methods, for more
> Java-friendly APIs.

Ah, ok, then the question was misleading in another way :-).
Syntax and API made a difference to me.

Then it arouses the general question of keeping the
mapping results as lean as possible or bloating it
up with convenience elements for the sake of most
possible Java interop, even if they will be used
seldom to never in a specific project.
I.e.: what priority has the Java -> Scala interoperability
in the eyes of the Scala designers and the Scala users?

My spontaneous answer would be: Interop is on the JVM
level, not the Java-level. As long as anything is possible,
it must not be convenient in this regard.
Either one can explicitly target the Scala API to Java
usability (avoid scala-isms), or one can create an access
layer to the Scala part (encapsulate/hide the annoyance).

Just my 2ct
Det

>
> -------------------------------------
> Detering Dirk wrote:
>
> > 2009/10/5 Paul Phillips :
> > > The inner object is lifted.
> > >
> > > scala> Outer$Inner$.MODULE$.c
> > > res0: Int = 1
> > >
> > > Or in java:
> > >
> > >  Outer$Inner$.MODULE$.c()
>
> > From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> >
> > Is there any plan to improve the syntax?
>
> ?? This question seems somewhat misleading to me...
>
> Scalac is IMHO not primarily a Java code generator.
>
> AFAIU Scala compiles by mapping the language constructs to
> the JVM concepts, and when trying to access that from Java
> you certainly become aware of that mapping results.
>
> So "improving the syntax" would imply remodeling the way
> Scala maps to the JVM which for me seems to be a very deep impact.
>
> KR
> Det
>
>

Detering Dirk schrieb:
>> -----Original Message-----
>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>
>> It means adding static forwarding methods, for more
>> Java-friendly APIs.
>
> Ah, ok, then the question was misleading in another way :-).
> Syntax and API made a difference to me.
>
> Then it arouses the general question of keeping the
> mapping results as lean as possible or bloating it
> up with convenience elements for the sake of most
> possible Java interop, even if they will be used
> seldom to never in a specific project.
> I.e.: what priority has the Java -> Scala interoperability
> in the eyes of the Scala designers and the Scala users?

Well, I would call me a Scala und Java user and I'm interested in a good interoperability, because I want to use Scala for internal and external DSLs and for all the problems that can be easily solved by functional programming languages. On the other hand, I suppose Scala is not suitable when you need the "maximal" runtime performance (I've read in some blogs and forums that Scala is sometimes 100 times slower than Java).

Furthermore the Java<->Scala interoperability is important in both directions if you work together in a team of Scala and Java programmers that don't want to learn another programming language. IMO the most important reason to use Scala instead of Haskell or other functional programming languages it's compatibility to Java and not the ability to run in a JVM, since most of the function programming languages are also platform independent.

Regards,
Stefan

>
> My spontaneous answer would be: Interop is on the JVM
> level, not the Java-level. As long as anything is possible,
> it must not be convenient in this regard.
> Either one can explicitly target the Scala API to Java
> usability (avoid scala-isms), or one can create an access
> layer to the Scala part (encapsulate/hide the annoyance).
>
> Just my 2ct
> Det
>
>
>> -------------------------------------
>> Detering Dirk wrote:
>>
>>> 2009/10/5 Paul Phillips :
>>>> The inner object is lifted.
>>>>
>>>> scala> Outer$Inner$.MODULE$.c
>>>> res0: Int = 1
>>>>
>>>> Or in java:
>>>>
>>>> Outer$Inner$.MODULE$.c()
>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>
>>> Is there any plan to improve the syntax?
>> ?? This question seems somewhat misleading to me...
>>
>> Scalac is IMHO not primarily a Java code generator.
>>
>> AFAIU Scala compiles by mapping the language constructs to
>> the JVM concepts, and when trying to access that from Java
>> you certainly become aware of that mapping results.
>>
>> So "improving the syntax" would imply remodeling the way
>> Scala maps to the JVM which for me seems to be a very deep impact.
>>
>> KR
>> Det
>>
>>
>

You have to be pretty determined to write Scala that's 100 times
slower than Java. I think you might have been reading about Ruby or
Python rather than Scala when you read that.

That said, there are some points at which Scala is a bit slower than
Java. Those are being worked on.

2009/10/6 Stefan Endrullis :
> Detering Dirk schrieb:
>>> -----Original Message-----
>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>
>>> It means adding static forwarding methods, for more
>>> Java-friendly APIs.
>>
>> Ah, ok, then the question was misleading in another way :-).
>> Syntax and API made a difference to me.
>>
>> Then it arouses the general question of keeping the
>> mapping results as lean as possible or bloating it
>> up with convenience elements for the sake of most
>> possible Java interop, even if they will be used
>> seldom to never in a specific project.
>> I.e.: what priority has the Java -> Scala interoperability
>> in the eyes of the Scala designers and the Scala users?
>
> Well, I would call me a Scala und Java user and I'm interested in a good interoperability, because I want to use Scala for internal and external DSLs and for all the problems that can be easily solved by functional programming languages. On the other hand, I suppose Scala is not suitable when you need the "maximal" runtime performance (I've read in some blogs and forums that Scala is sometimes 100 times slower than Java).
>
> Furthermore the Java<->Scala interoperability is important in both directions if you work together in a team of Scala and Java programmers that don't want to learn another programming language. IMO the most important reason to use Scala instead of Haskell or other functional programming languages it's compatibility to Java and not the ability to run in a JVM, since most of the function programming languages are also platform independent.
>
> Regards,
> Stefan
>
>>
>> My spontaneous answer would be: Interop is on the JVM
>> level, not the Java-level. As long as anything is possible,
>> it must not be convenient in this regard.
>> Either one can explicitly target the Scala API to Java
>> usability (avoid scala-isms), or one can create an access
>> layer to the Scala part (encapsulate/hide the annoyance).
>>
>> Just my 2ct
>> Det
>>
>>
>>> -------------------------------------
>>> Detering Dirk wrote:
>>>
>>>> 2009/10/5 Paul Phillips :
>>>>> The inner object is lifted.
>>>>>
>>>>> scala> Outer$Inner$.MODULE$.c
>>>>> res0: Int = 1
>>>>>
>>>>> Or in java:
>>>>>
>>>>>  Outer$Inner$.MODULE$.c()
>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>
>>>> Is there any plan to improve the syntax?
>>> ?? This question seems somewhat misleading to me...
>>>
>>> Scalac is IMHO not primarily a Java code generator.
>>>
>>> AFAIU Scala compiles by mapping the language constructs to
>>> the JVM concepts, and when trying to access that from Java
>>> you certainly become aware of that mapping results.
>>>
>>> So "improving the syntax" would imply remodeling the way
>>> Scala maps to the JVM which for me seems to be a very deep impact.
>>>
>>> KR
>>> Det
>>>
>>>
>>
>
>

Hi,

On Tue, 2009-10-06 at 11:22 +0200, Stefan Endrullis wrote:
> On the other hand, I suppose Scala is not suitable when you need the "maximal"
> runtime performance (I've read in some blogs and forums that Scala is
> sometimes 100 times slower than Java).

100 times slower sounds like a contrived benchmark. For a certain type
of numerical code, idiomatic Scala can be perhaps 10 times slower than
the same code written in a more imperative style in either Scala or
Java.

The key observation above is that you can achieve the same performance
in Scala as in Java if you're willing to use the same programming style
(ok, in Scala you have to use a while loop instead of a for loop and
that is a bit uglier).

Work is being done to improve the performance of idiomatic Scala code
that deals with numerics and we may even get some of that for 2.8.0.

Best,
Ismael

I think you are right. Those blogs were not objective. I found some hopefully objective benchmarks on debian.org:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&d=...
In average, Scala seems to be only 2 times slower that Java. Well, that sounds not bad!

Regards,
Stefan

Ricky Clarkson schrieb:
> You have to be pretty determined to write Scala that's 100 times
> slower than Java. I think you might have been reading about Ruby or
> Python rather than Scala when you read that.
>
> That said, there are some points at which Scala is a bit slower than
> Java. Those are being worked on.
>
> 2009/10/6 Stefan Endrullis :
>> Detering Dirk schrieb:
>>>> -----Original Message-----
>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>
>>>> It means adding static forwarding methods, for more
>>>> Java-friendly APIs.
>>> Ah, ok, then the question was misleading in another way :-).
>>> Syntax and API made a difference to me.
>>>
>>> Then it arouses the general question of keeping the
>>> mapping results as lean as possible or bloating it
>>> up with convenience elements for the sake of most
>>> possible Java interop, even if they will be used
>>> seldom to never in a specific project.
>>> I.e.: what priority has the Java -> Scala interoperability
>>> in the eyes of the Scala designers and the Scala users?
>> Well, I would call me a Scala und Java user and I'm interested in a good interoperability, because I want to use Scala for internal and external DSLs and for all the problems that can be easily solved by functional programming languages. On the other hand, I suppose Scala is not suitable when you need the "maximal" runtime performance (I've read in some blogs and forums that Scala is sometimes 100 times slower than Java).
>>
>> Furthermore the Java<->Scala interoperability is important in both directions if you work together in a team of Scala and Java programmers that don't want to learn another programming language. IMO the most important reason to use Scala instead of Haskell or other functional programming languages it's compatibility to Java and not the ability to run in a JVM, since most of the function programming languages are also platform independent.
>>
>> Regards,
>> Stefan
>>
>>> My spontaneous answer would be: Interop is on the JVM
>>> level, not the Java-level. As long as anything is possible,
>>> it must not be convenient in this regard.
>>> Either one can explicitly target the Scala API to Java
>>> usability (avoid scala-isms), or one can create an access
>>> layer to the Scala part (encapsulate/hide the annoyance).
>>>
>>> Just my 2ct
>>> Det
>>>
>>>
>>>> -------------------------------------
>>>> Detering Dirk wrote:
>>>>
>>>>> 2009/10/5 Paul Phillips :
>>>>>> The inner object is lifted.
>>>>>>
>>>>>> scala> Outer$Inner$.MODULE$.c
>>>>>> res0: Int = 1
>>>>>>
>>>>>> Or in java:
>>>>>>
>>>>>> Outer$Inner$.MODULE$.c()
>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>
>>>>> Is there any plan to improve the syntax?
>>>> ?? This question seems somewhat misleading to me...
>>>>
>>>> Scalac is IMHO not primarily a Java code generator.
>>>>
>>>> AFAIU Scala compiles by mapping the language constructs to
>>>> the JVM concepts, and when trying to access that from Java
>>>> you certainly become aware of that mapping results.
>>>>
>>>> So "improving the syntax" would imply remodeling the way
>>>> Scala maps to the JVM which for me seems to be a very deep impact.
>>>>
>>>> KR
>>>> Det
>>>>
>>>>
>>
>
>
>

For me it's about using the right tools for the right jobs.
Perhaps if you need to do number-crunching, you should have a look at OpenCL instead.

For me correctness is more important than speed of execution, because hardware gets better and better, and incorrectness only gets worst with increase of execution speed.

On Tue, Oct 6, 2009 at 11:46 AM, Ismael Juma <mlists@juma.me.uk> wrote:

Hi,

On Tue, 2009-10-06 at 11:22 +0200, Stefan Endrullis wrote:
> On the other hand, I suppose Scala is not suitable when you need the "maximal"
> runtime performance (I've read in some blogs and forums that Scala is
> sometimes 100 times slower than Java).

100 times slower sounds like a contrived benchmark. For a certain type
of numerical code, idiomatic Scala can be perhaps 10 times slower than
the same code written in a more imperative style in either Scala or
Java.

The key observation above is that you can achieve the same performance
in Scala as in Java if you're willing to use the same programming style
(ok, in Scala you have to use a while loop instead of a for loop and
that is a bit uglier).

Work is being done to improve the performance of idiomatic Scala code
that deals with numerics and we may even get some of that for 2.8.0.

Best,
Ismael

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

On Tue, 2009-10-06 at 11:50 +0200, Viktor Klang wrote:
> For me it's about using the right tools for the right jobs.

It's rarely that black and white though. There are often many applicable
tools with different trade-offs. :)

> Perhaps if you need to do number-crunching, you should have a look at
> OpenCL instead.

Maybe, but that involves more work. Performance requirements vary and
sometimes a while loop over an array in a tight loop gives you enough of
an improvement over map that it's good enough. Also, you may not even
have the hardware required to run OpenCL efficiently in your existing
cluster.

> For me correctness is more important than speed of execution, because
> hardware gets better and better, and incorrectness only gets worst
> with increase of execution speed.

Correctness is more important, but correctness is application dependent.
Using doubles is perfectly fine for many types of applications, for
example.

Best,
Ismael

On Tue, Oct 6, 2009 at 12:24 PM, Ismael Juma <mlists@juma.me.uk> wrote:

On Tue, 2009-10-06 at 11:50 +0200, Viktor Klang wrote:
> For me it's about using the right tools for the right jobs.

It's rarely that black and white though. There are often many applicable
tools with different trade-offs. :)

"right tool" for me is the one that best fits the requirements :)
 

> Perhaps if you need to do number-crunching, you should have a look at
> OpenCL instead.

Maybe, but that involves more work. Performance requirements vary and
sometimes a while loop over an array in a tight loop gives you enough of
an improvement over map that it's good enough. Also, you may not even
have the hardware required to run OpenCL efficiently in your existing
cluster.

Then that's something that potentially could generate alot of revenue for a developer - creating an easy-to-use OpenCL library that interfaces with alot of different platforms.
 

> For me correctness is more important than speed of execution, because
> hardware gets better and better, and incorrectness only gets worst
> with increase of execution speed.

Correctness is more important, but correctness is application dependent.
Using doubles is perfectly fine for many types of applications, for
example.

Doubles and floats are per definition incorrect, since it's impossible to represent a lot of numbers using them.
It still strikes me as kind of retarded that Java has native support for them, but not for arbitrary precision decimals. (let's not reiterate the BigDecimal discussion ;) )

 

Best,
Ismael

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

> I think you are right. Those blogs were not objective. I
> found some hopefully objective benchmarks on debian.org:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&l
> ang=all&d=data&javaxx=on&java=on&javaclient=on&scala=on&ruby=o
> n&calc=calculate&box=1
> In average, Scala seems to be only 2 times slower that Java.
> Well, that sounds not bad!

I do not understand the precise statement of that comparision.

There is only "Scala" but three "Java 6" entries, each differing in
the parametrisation of the JVM. Regarding the fact that Scala
runs on said JVM, may it be possible that only the "Java 6 -client"
comparision is applicable?

Then "in average only 2 times" seems wrong. (BTW: Version was 2.7.1)
(median java6 -client = 2.30 vs. median scala = 2.87)

For all other variants a comparable parametrisation should be used when
starting the JVM under Scala.

KR
Det

>
> Regards,
> Stefan
>
> Ricky Clarkson schrieb:
> > You have to be pretty determined to write Scala that's 100 times
> > slower than Java. I think you might have been reading
> about Ruby or
> > Python rather than Scala when you read that.
> >
> > That said, there are some points at which Scala is a bit
> slower than
> > Java. Those are being worked on.
> >
> > 2009/10/6 Stefan Endrullis :
> >> Detering Dirk schrieb:
> >>>> -----Original Message-----
> >>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> >>>>
> >>>> It means adding static forwarding methods, for more
> Java-friendly
> >>>> APIs.
> >>> Ah, ok, then the question was misleading in another way :-).
> >>> Syntax and API made a difference to me.
> >>>
> >>> Then it arouses the general question of keeping the
> mapping results
> >>> as lean as possible or bloating it up with convenience
> elements for
> >>> the sake of most possible Java interop, even if they will be used
> >>> seldom to never in a specific project.
> >>> I.e.: what priority has the Java -> Scala interoperability in the
> >>> eyes of the Scala designers and the Scala users?
> >> Well, I would call me a Scala und Java user and I'm
> interested in a good interoperability, because I want to use
> Scala for internal and external DSLs and for all the problems
> that can be easily solved by functional programming
> languages. On the other hand, I suppose Scala is not suitable
> when you need the "maximal" runtime performance (I've read in
> some blogs and forums that Scala is sometimes 100 times
> slower than Java).
> >>
> >> Furthermore the Java<->Scala interoperability is important
> in both directions if you work together in a team of Scala
> and Java programmers that don't want to learn another
> programming language. IMO the most important reason to use
> Scala instead of Haskell or other functional programming
> languages it's compatibility to Java and not the ability to
> run in a JVM, since most of the function programming
> languages are also platform independent.
> >>
> >> Regards,
> >> Stefan
> >>
> >>> My spontaneous answer would be: Interop is on the JVM
> level, not the
> >>> Java-level. As long as anything is possible, it must not be
> >>> convenient in this regard.
> >>> Either one can explicitly target the Scala API to Java usability
> >>> (avoid scala-isms), or one can create an access layer to
> the Scala
> >>> part (encapsulate/hide the annoyance).
> >>>
> >>> Just my 2ct
> >>> Det
> >>>
> >>>
> >>>> -------------------------------------
> >>>> Detering Dirk wrote:
> >>>>
> >>>>> 2009/10/5 Paul Phillips :
> >>>>>> The inner object is lifted.
> >>>>>>
> >>>>>> scala> Outer$Inner$.MODULE$.c
> >>>>>> res0: Int = 1
> >>>>>>
> >>>>>> Or in java:
> >>>>>>
> >>>>>> Outer$Inner$.MODULE$.c()
> >>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> >>>>>
> >>>>> Is there any plan to improve the syntax?
> >>>> ?? This question seems somewhat misleading to me...
> >>>>
> >>>> Scalac is IMHO not primarily a Java code generator.
> >>>>
> >>>> AFAIU Scala compiles by mapping the language constructs
> to the JVM
> >>>> concepts, and when trying to access that from Java you certainly
> >>>> become aware of that mapping results.
> >>>>
> >>>> So "improving the syntax" would imply remodeling the way
> Scala maps
> >>>> to the JVM which for me seems to be a very deep impact.
> >>>>
> >>>> KR
> >>>> Det
> >>>>
> >>>>
> >>
> >
> >
> >
>
>

On Tue, Oct 6, 2009 at 1:48 PM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

> I think you are right. Those blogs were not objective. I
> found some hopefully objective benchmarks on debian.org:
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&l
> ang=all&d=data&javaxx=on&java=on&javaclient=on&scala=on&ruby=o
> n&calc=calculate&box=1
> In average, Scala seems to be only 2 times slower that Java.
> Well, that sounds not bad!

I do not understand the precise statement of that comparision.

There is only "Scala" but three "Java 6" entries, each differing in
the parametrisation of the JVM. Regarding the fact that Scala
runs on said JVM, may it be possible that only the "Java 6 -client"
comparision is applicable?

Then "in average only 2 times" seems wrong. (BTW: Version was 2.7.1)
(median java6 -client = 2.30 vs. median scala = 2.87)

For all other variants a comparable parametrisation should be used when
starting the JVM under Scala.

Also, from what I could tell, it is running Scala 2.7.1
 

KR
Det



>
> Regards,
> Stefan
>
> Ricky Clarkson schrieb:
> > You have to be pretty determined to write Scala that's 100 times
> > slower than Java.  I think you might have been reading
> about Ruby or
> > Python rather than Scala when you read that.
> >
> > That said, there are some points at which Scala is a bit
> slower than
> > Java.  Those are being worked on.
> >
> > 2009/10/6 Stefan Endrullis <stefan@endrullis.de>:
> >> Detering Dirk schrieb:
> >>>> -----Original Message-----
> >>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> >>>>
> >>>> It means adding static forwarding methods, for more
> Java-friendly
> >>>> APIs.
> >>> Ah, ok, then the question was misleading in another way :-).
> >>> Syntax and API made a difference to me.
> >>>
> >>> Then it arouses the general question of keeping the
> mapping results
> >>> as lean as possible or bloating it up with convenience
> elements for
> >>> the sake of most possible Java interop, even if they will be used
> >>> seldom to never in a specific project.
> >>> I.e.: what priority has the Java -> Scala interoperability in the
> >>> eyes of the Scala designers and the Scala users?
> >> Well, I would call me a Scala und Java user and I'm
> interested in a good interoperability, because I want to use
> Scala for internal and external DSLs and for all the problems
> that can be easily solved by functional programming
> languages. On the other hand, I suppose Scala is not suitable
> when you need the "maximal" runtime performance (I've read in
> some blogs and forums that Scala is sometimes 100 times
> slower than Java).
> >>
> >> Furthermore the Java<->Scala interoperability is important
> in both directions if you work together in a team of Scala
> and Java programmers that don't want to learn another
> programming language. IMO the most important reason to use
> Scala instead of Haskell or other functional programming
> languages it's compatibility to Java and not the ability to
> run in a JVM, since most of the function programming
> languages are also platform independent.
> >>
> >> Regards,
> >> Stefan
> >>
> >>> My spontaneous answer would be: Interop is on the JVM
> level, not the
> >>> Java-level. As long as anything is possible, it must not be
> >>> convenient in this regard.
> >>> Either one can explicitly target the Scala API to Java usability
> >>> (avoid scala-isms), or one can create an access layer to
> the Scala
> >>> part (encapsulate/hide the annoyance).
> >>>
> >>> Just my 2ct
> >>> Det
> >>>
> >>>
> >>>> -------------------------------------
> >>>> Detering Dirk<dirk.detering@bitmarck.de> wrote:
> >>>>
> >>>>> 2009/10/5 Paul Phillips <paulp@improving.org>:
> >>>>>> The inner object is lifted.
> >>>>>>
> >>>>>> scala> Outer$Inner$.MODULE$.c
> >>>>>> res0: Int = 1
> >>>>>>
> >>>>>> Or in java:
> >>>>>>
> >>>>>>  Outer$Inner$.MODULE$.c()
> >>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> >>>>>
> >>>>> Is there any plan to improve the syntax?
> >>>> ?? This question seems somewhat misleading to me...
> >>>>
> >>>> Scalac is IMHO not primarily a Java code generator.
> >>>>
> >>>> AFAIU Scala compiles by mapping the language constructs
> to the JVM
> >>>> concepts, and when trying to access that from Java you certainly
> >>>> become aware of that mapping results.
> >>>>
> >>>> So "improving the syntax" would imply remodeling the way
> Scala maps
> >>>> to the JVM which for me seems to be a very deep impact.
> >>>>
> >>>> KR
> >>>> Det
> >>>>
> >>>>
> >>
> >
> >
> >
>
>

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

On 6 Oct 2009, at 08:40, Detering Dirk wrote:

>> -----Original Message-----
>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>
>> It means adding static forwarding methods, for more
>> Java-friendly APIs.
>
> Ah, ok, then the question was misleading in another way :-).
> Syntax and API made a difference to me.
>
> Then it arouses the general question of keeping the
> mapping results as lean as possible or bloating it
> up with convenience elements for the sake of most
> possible Java interop, even if they will be used
> seldom to never in a specific project.

That raises a couple of interesting possibilities:

What about some kind of compile-time flag which makes the generated
bytecodes as Java- (or CLR-language-) friendly as possible, at the
expense of some bloating? You'd use that if you were writing an API to
be consumed by other languages.

Or else annotations on particular interfaces, in the spirit of
@BeanProperty

For the stuff I’m writing (stand-alone apps), the opposite would be
more useful to me: highly optimised class files which do not even have
to be compatible with separately-compiled Scala code. (Again, in that
case, it would be useful to declare certain APIs as requiring external
compatibility.)

–Andrew

Yes, unfortunately it's not clear what virtual machine parameters have been used for executing the Scala programs. I just assumes they used "-server" because that's known to speed up the runtime execution at the cost of a slightly (~20%) longer start phase. But maybe I'm wrong and Scala is even faster then factor 2 that I assumed in my last post.

Regards,
Stefan

Detering Dirk schrieb:
>> I think you are right. Those blogs were not objective. I
>> found some hopefully objective benchmarks on debian.org:
>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&l
>> ang=all&d=data&javaxx=on&java=on&javaclient=on&scala=on&ruby=o
>> n&calc=calculate&box=1
>> In average, Scala seems to be only 2 times slower that Java.
>> Well, that sounds not bad!
>
> I do not understand the precise statement of that comparision.
>
> There is only "Scala" but three "Java 6" entries, each differing in
> the parametrisation of the JVM. Regarding the fact that Scala
> runs on said JVM, may it be possible that only the "Java 6 -client"
> comparision is applicable?
>
> Then "in average only 2 times" seems wrong. (BTW: Version was 2.7.1)
> (median java6 -client = 2.30 vs. median scala = 2.87)
>
> For all other variants a comparable parametrisation should be used when
> starting the JVM under Scala.
>
> KR
> Det
>
>
>
>> Regards,
>> Stefan
>>
>> Ricky Clarkson schrieb:
>>> You have to be pretty determined to write Scala that's 100 times
>>> slower than Java. I think you might have been reading
>> about Ruby or
>>> Python rather than Scala when you read that.
>>>
>>> That said, there are some points at which Scala is a bit
>> slower than
>>> Java. Those are being worked on.
>>>
>>> 2009/10/6 Stefan Endrullis :
>>>> Detering Dirk schrieb:
>>>>>> -----Original Message-----
>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>
>>>>>> It means adding static forwarding methods, for more
>> Java-friendly
>>>>>> APIs.
>>>>> Ah, ok, then the question was misleading in another way :-).
>>>>> Syntax and API made a difference to me.
>>>>>
>>>>> Then it arouses the general question of keeping the
>> mapping results
>>>>> as lean as possible or bloating it up with convenience
>> elements for
>>>>> the sake of most possible Java interop, even if they will be used
>>>>> seldom to never in a specific project.
>>>>> I.e.: what priority has the Java -> Scala interoperability in the
>>>>> eyes of the Scala designers and the Scala users?
>>>> Well, I would call me a Scala und Java user and I'm
>> interested in a good interoperability, because I want to use
>> Scala for internal and external DSLs and for all the problems
>> that can be easily solved by functional programming
>> languages. On the other hand, I suppose Scala is not suitable
>> when you need the "maximal" runtime performance (I've read in
>> some blogs and forums that Scala is sometimes 100 times
>> slower than Java).
>>>> Furthermore the Java<->Scala interoperability is important
>> in both directions if you work together in a team of Scala
>> and Java programmers that don't want to learn another
>> programming language. IMO the most important reason to use
>> Scala instead of Haskell or other functional programming
>> languages it's compatibility to Java and not the ability to
>> run in a JVM, since most of the function programming
>> languages are also platform independent.
>>>> Regards,
>>>> Stefan
>>>>
>>>>> My spontaneous answer would be: Interop is on the JVM
>> level, not the
>>>>> Java-level. As long as anything is possible, it must not be
>>>>> convenient in this regard.
>>>>> Either one can explicitly target the Scala API to Java usability
>>>>> (avoid scala-isms), or one can create an access layer to
>> the Scala
>>>>> part (encapsulate/hide the annoyance).
>>>>>
>>>>> Just my 2ct
>>>>> Det
>>>>>
>>>>>
>>>>>> -------------------------------------
>>>>>> Detering Dirk wrote:
>>>>>>
>>>>>>> 2009/10/5 Paul Phillips :
>>>>>>>> The inner object is lifted.
>>>>>>>>
>>>>>>>> scala> Outer$Inner$.MODULE$.c
>>>>>>>> res0: Int = 1
>>>>>>>>
>>>>>>>> Or in java:
>>>>>>>>
>>>>>>>> Outer$Inner$.MODULE$.c()
>>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>>
>>>>>>> Is there any plan to improve the syntax?
>>>>>> ?? This question seems somewhat misleading to me...
>>>>>>
>>>>>> Scalac is IMHO not primarily a Java code generator.
>>>>>>
>>>>>> AFAIU Scala compiles by mapping the language constructs
>> to the JVM
>>>>>> concepts, and when trying to access that from Java you certainly
>>>>>> become aware of that mapping results.
>>>>>>
>>>>>> So "improving the syntax" would imply remodeling the way
>> Scala maps
>>>>>> to the JVM which for me seems to be a very deep impact.
>>>>>>
>>>>>> KR
>>>>>> Det
>>>>>>
>>>>>>
>>>
>>>
>>
>

The numbers I've heard at a seminar and read online is that Groovy is
100 times slower than Java, not that Scala is 100 times slower.
Since Groovy is interpreted, it makes sense that it would have slower
performance.

-Mike

On Tue, Oct 6, 2009 at 8:50 AM, Stefan Endrullis wrote:
> Yes, unfortunately it's not clear what virtual machine parameters have been used for executing the Scala programs. I just assumes they used "-server" because that's known to speed up the runtime execution at the cost of a slightly (~20%) longer start phase. But maybe I'm wrong and Scala is even faster then factor 2 that I assumed in my last post.
>
> Regards,
> Stefan
>
> Detering Dirk schrieb:
>>> I think you are right. Those blogs were not objective. I
>>> found some hopefully objective benchmarks on debian.org:
>>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&l
>>> ang=all&d=data&javaxx=on&java=on&javaclient=on&scala=on&ruby=o
>>> n&calc=calculate&box=1
>>> In average, Scala seems to be only 2 times slower that Java.
>>> Well, that sounds not bad!
>>
>> I do not understand the precise statement of that comparision.
>>
>> There is only "Scala" but three "Java 6" entries, each differing in
>> the parametrisation of the JVM. Regarding the fact that Scala
>> runs on said JVM, may it be possible that only the "Java 6 -client"
>> comparision is applicable?
>>
>> Then "in average only 2 times" seems wrong. (BTW: Version was 2.7.1)
>> (median java6 -client = 2.30 vs. median scala = 2.87)
>>
>> For all other variants a comparable parametrisation should be used when
>> starting the JVM under Scala.
>>
>> KR
>> Det
>>
>>
>>
>>> Regards,
>>> Stefan
>>>
>>> Ricky Clarkson schrieb:
>>>> You have to be pretty determined to write Scala that's 100 times
>>>> slower than Java.  I think you might have been reading
>>> about Ruby or
>>>> Python rather than Scala when you read that.
>>>>
>>>> That said, there are some points at which Scala is a bit
>>> slower than
>>>> Java.  Those are being worked on.
>>>>
>>>> 2009/10/6 Stefan Endrullis :
>>>>> Detering Dirk schrieb:
>>>>>>> -----Original Message-----
>>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>>
>>>>>>> It means adding static forwarding methods, for more
>>> Java-friendly
>>>>>>> APIs.
>>>>>> Ah, ok, then the question was misleading in another way :-).
>>>>>> Syntax and API made a difference to me.
>>>>>>
>>>>>> Then it arouses the general question of keeping the
>>> mapping results
>>>>>> as lean as possible or bloating it up with convenience
>>> elements for
>>>>>> the sake of most possible Java interop, even if they will be used
>>>>>> seldom to never in a specific project.
>>>>>> I.e.: what priority has the Java -> Scala interoperability in the
>>>>>> eyes of the Scala designers and the Scala users?
>>>>> Well, I would call me a Scala und Java user and I'm
>>> interested in a good interoperability, because I want to use
>>> Scala for internal and external DSLs and for all the problems
>>> that can be easily solved by functional programming
>>> languages. On the other hand, I suppose Scala is not suitable
>>> when you need the "maximal" runtime performance (I've read in
>>> some blogs and forums that Scala is sometimes 100 times
>>> slower than Java).
>>>>> Furthermore the Java<->Scala interoperability is important
>>> in both directions if you work together in a team of Scala
>>> and Java programmers that don't want to learn another
>>> programming language. IMO the most important reason to use
>>> Scala instead of Haskell or other functional programming
>>> languages it's compatibility to Java and not the ability to
>>> run in a JVM, since most of the function programming
>>> languages are also platform independent.
>>>>> Regards,
>>>>> Stefan
>>>>>
>>>>>> My spontaneous answer would be: Interop is on the JVM
>>> level, not the
>>>>>> Java-level. As long as anything is possible, it must not be
>>>>>> convenient in this regard.
>>>>>> Either one can explicitly target the Scala API to Java usability
>>>>>> (avoid scala-isms), or one can create an access layer to
>>> the Scala
>>>>>> part (encapsulate/hide the annoyance).
>>>>>>
>>>>>> Just my 2ct
>>>>>> Det
>>>>>>
>>>>>>
>>>>>>> -------------------------------------
>>>>>>> Detering Dirk wrote:
>>>>>>>
>>>>>>>> 2009/10/5 Paul Phillips :
>>>>>>>>> The inner object is lifted.
>>>>>>>>>
>>>>>>>>> scala> Outer$Inner$.MODULE$.c
>>>>>>>>> res0: Int = 1
>>>>>>>>>
>>>>>>>>> Or in java:
>>>>>>>>>
>>>>>>>>>  Outer$Inner$.MODULE$.c()
>>>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>>>
>>>>>>>> Is there any plan to improve the syntax?
>>>>>>> ?? This question seems somewhat misleading to me...
>>>>>>>
>>>>>>> Scalac is IMHO not primarily a Java code generator.
>>>>>>>
>>>>>>> AFAIU Scala compiles by mapping the language constructs
>>> to the JVM
>>>>>>> concepts, and when trying to access that from Java you certainly
>>>>>>> become aware of that mapping results.
>>>>>>>
>>>>>>> So "improving the syntax" would imply remodeling the way
>>> Scala maps
>>>>>>> to the JVM which for me seems to be a very deep impact.
>>>>>>>
>>>>>>> KR
>>>>>>> Det
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>
>

It is indeed run with -server.  For example:

COMMAND LINE:
 /usr/bin/java -server -Xbootclasspath/a:/usr/local/src/scala-2.7.6.final/lib/scala-library.jar mandelbrot 16000

But some of the superior Java performance is because of JNI access to specialized libraries (e.g. using the highly-optimized (both for hardware and algorithmically) GMP library instead of BigDecimal) that no-one has bothered to replicate for Scala.  I'd generally characterize the slowdown for using Scala as "less than a factor of two".  The median scores of 2.62 for Scala vs. 1.93 for Java seem about right to me (i.e. ~35% slower) *if* you are determined to write Scala that performs well.

  --Rex


On Tue, Oct 6, 2009 at 8:50 AM, Stefan Endrullis <stefan@endrullis.de> wrote:

Yes, unfortunately it's not clear what virtual machine parameters have been used for executing the Scala programs. I just assumes they used "-server" because that's known to speed up the runtime execution at the cost of a slightly (~20%) longer start phase. But maybe I'm wrong and Scala is even faster then factor 2 that I assumed in my last post.

Regards,
Stefan

Detering Dirk schrieb:
>> I think you are right. Those blogs were not objective. I
>> found some hopefully objective benchmarks on debian.org:
>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&l
>> ang=all&d=data&javaxx=on&java=on&javaclient=on&scala=on&ruby=o
>> n&calc=calculate&box=1
>> In average, Scala seems to be only 2 times slower that Java.
>> Well, that sounds not bad!
>
> I do not understand the precise statement of that comparision.
>
> There is only "Scala" but three "Java 6" entries, each differing in
> the parametrisation of the JVM. Regarding the fact that Scala
> runs on said JVM, may it be possible that only the "Java 6 -client"
> comparision is applicable?
>
> Then "in average only 2 times" seems wrong. (BTW: Version was 2.7.1)
> (median java6 -client = 2.30 vs. median scala = 2.87)
>
> For all other variants a comparable parametrisation should be used when
> starting the JVM under Scala.
>
> KR
> Det
>
>
>
>> Regards,
>> Stefan
>>
>> Ricky Clarkson schrieb:
>>> You have to be pretty determined to write Scala that's 100 times
>>> slower than Java.  I think you might have been reading
>> about Ruby or
>>> Python rather than Scala when you read that.
>>>
>>> That said, there are some points at which Scala is a bit
>> slower than
>>> Java.  Those are being worked on.
>>>
>>> 2009/10/6 Stefan Endrullis <stefan@endrullis.de>:
>>>> Detering Dirk schrieb:
>>>>>> -----Original Message-----
>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>
>>>>>> It means adding static forwarding methods, for more
>> Java-friendly
>>>>>> APIs.
>>>>> Ah, ok, then the question was misleading in another way :-).
>>>>> Syntax and API made a difference to me.
>>>>>
>>>>> Then it arouses the general question of keeping the
>> mapping results
>>>>> as lean as possible or bloating it up with convenience
>> elements for
>>>>> the sake of most possible Java interop, even if they will be used
>>>>> seldom to never in a specific project.
>>>>> I.e.: what priority has the Java -> Scala interoperability in the
>>>>> eyes of the Scala designers and the Scala users?
>>>> Well, I would call me a Scala und Java user and I'm
>> interested in a good interoperability, because I want to use
>> Scala for internal and external DSLs and for all the problems
>> that can be easily solved by functional programming
>> languages. On the other hand, I suppose Scala is not suitable
>> when you need the "maximal" runtime performance (I've read in
>> some blogs and forums that Scala is sometimes 100 times
>> slower than Java).
>>>> Furthermore the Java<->Scala interoperability is important
>> in both directions if you work together in a team of Scala
>> and Java programmers that don't want to learn another
>> programming language. IMO the most important reason to use
>> Scala instead of Haskell or other functional programming
>> languages it's compatibility to Java and not the ability to
>> run in a JVM, since most of the function programming
>> languages are also platform independent.
>>>> Regards,
>>>> Stefan
>>>>
>>>>> My spontaneous answer would be: Interop is on the JVM
>> level, not the
>>>>> Java-level. As long as anything is possible, it must not be
>>>>> convenient in this regard.
>>>>> Either one can explicitly target the Scala API to Java usability
>>>>> (avoid scala-isms), or one can create an access layer to
>> the Scala
>>>>> part (encapsulate/hide the annoyance).
>>>>>
>>>>> Just my 2ct
>>>>> Det
>>>>>
>>>>>
>>>>>> -------------------------------------
>>>>>> Detering Dirk<dirk.detering@bitmarck.de> wrote:
>>>>>>
>>>>>>> 2009/10/5 Paul Phillips <paulp@improving.org>:
>>>>>>>> The inner object is lifted.
>>>>>>>>
>>>>>>>> scala> Outer$Inner$.MODULE$.c
>>>>>>>> res0: Int = 1
>>>>>>>>
>>>>>>>> Or in java:
>>>>>>>>
>>>>>>>>  Outer$Inner$.MODULE$.c()
>>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>>
>>>>>>> Is there any plan to improve the syntax?
>>>>>> ?? This question seems somewhat misleading to me...
>>>>>>
>>>>>> Scalac is IMHO not primarily a Java code generator.
>>>>>>
>>>>>> AFAIU Scala compiles by mapping the language constructs
>> to the JVM
>>>>>> concepts, and when trying to access that from Java you certainly
>>>>>> become aware of that mapping results.
>>>>>>
>>>>>> So "improving the syntax" would imply remodeling the way
>> Scala maps
>>>>>> to the JVM which for me seems to be a very deep impact.
>>>>>>
>>>>>> KR
>>>>>> Det
>>>>>>
>>>>>>
>>>
>>>
>>
>

Groovy isn't interpreted, it's compiled. But Groovy bytecode will use
reflection a lot more than Scala's will. And fall over for fun. :)

2009/10/6 Michael Swierczek :
> The numbers I've heard at a seminar and read online is that Groovy is
> 100 times slower than Java, not that Scala is 100 times slower.
> Since Groovy is interpreted, it makes sense that it would have slower
> performance.
>
> -Mike
>
> On Tue, Oct 6, 2009 at 8:50 AM, Stefan Endrullis wrote:
>> Yes, unfortunately it's not clear what virtual machine parameters have been used for executing the Scala programs. I just assumes they used "-server" because that's known to speed up the runtime execution at the cost of a slightly (~20%) longer start phase. But maybe I'm wrong and Scala is even faster then factor 2 that I assumed in my last post.
>>
>> Regards,
>> Stefan
>>
>> Detering Dirk schrieb:
>>>> I think you are right. Those blogs were not objective. I
>>>> found some hopefully objective benchmarks on debian.org:
>>>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&l
>>>> ang=all&d=data&javaxx=on&java=on&javaclient=on&scala=on&ruby=o
>>>> n&calc=calculate&box=1
>>>> In average, Scala seems to be only 2 times slower that Java.
>>>> Well, that sounds not bad!
>>>
>>> I do not understand the precise statement of that comparision.
>>>
>>> There is only "Scala" but three "Java 6" entries, each differing in
>>> the parametrisation of the JVM. Regarding the fact that Scala
>>> runs on said JVM, may it be possible that only the "Java 6 -client"
>>> comparision is applicable?
>>>
>>> Then "in average only 2 times" seems wrong. (BTW: Version was 2.7.1)
>>> (median java6 -client = 2.30 vs. median scala = 2.87)
>>>
>>> For all other variants a comparable parametrisation should be used when
>>> starting the JVM under Scala.
>>>
>>> KR
>>> Det
>>>
>>>
>>>
>>>> Regards,
>>>> Stefan
>>>>
>>>> Ricky Clarkson schrieb:
>>>>> You have to be pretty determined to write Scala that's 100 times
>>>>> slower than Java.  I think you might have been reading
>>>> about Ruby or
>>>>> Python rather than Scala when you read that.
>>>>>
>>>>> That said, there are some points at which Scala is a bit
>>>> slower than
>>>>> Java.  Those are being worked on.
>>>>>
>>>>> 2009/10/6 Stefan Endrullis :
>>>>>> Detering Dirk schrieb:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>>>
>>>>>>>> It means adding static forwarding methods, for more
>>>> Java-friendly
>>>>>>>> APIs.
>>>>>>> Ah, ok, then the question was misleading in another way :-).
>>>>>>> Syntax and API made a difference to me.
>>>>>>>
>>>>>>> Then it arouses the general question of keeping the
>>>> mapping results
>>>>>>> as lean as possible or bloating it up with convenience
>>>> elements for
>>>>>>> the sake of most possible Java interop, even if they will be used
>>>>>>> seldom to never in a specific project.
>>>>>>> I.e.: what priority has the Java -> Scala interoperability in the
>>>>>>> eyes of the Scala designers and the Scala users?
>>>>>> Well, I would call me a Scala und Java user and I'm
>>>> interested in a good interoperability, because I want to use
>>>> Scala for internal and external DSLs and for all the problems
>>>> that can be easily solved by functional programming
>>>> languages. On the other hand, I suppose Scala is not suitable
>>>> when you need the "maximal" runtime performance (I've read in
>>>> some blogs and forums that Scala is sometimes 100 times
>>>> slower than Java).
>>>>>> Furthermore the Java<->Scala interoperability is important
>>>> in both directions if you work together in a team of Scala
>>>> and Java programmers that don't want to learn another
>>>> programming language. IMO the most important reason to use
>>>> Scala instead of Haskell or other functional programming
>>>> languages it's compatibility to Java and not the ability to
>>>> run in a JVM, since most of the function programming
>>>> languages are also platform independent.
>>>>>> Regards,
>>>>>> Stefan
>>>>>>
>>>>>>> My spontaneous answer would be: Interop is on the JVM
>>>> level, not the
>>>>>>> Java-level. As long as anything is possible, it must not be
>>>>>>> convenient in this regard.
>>>>>>> Either one can explicitly target the Scala API to Java usability
>>>>>>> (avoid scala-isms), or one can create an access layer to
>>>> the Scala
>>>>>>> part (encapsulate/hide the annoyance).
>>>>>>>
>>>>>>> Just my 2ct
>>>>>>> Det
>>>>>>>
>>>>>>>
>>>>>>>> -------------------------------------
>>>>>>>> Detering Dirk wrote:
>>>>>>>>
>>>>>>>>> 2009/10/5 Paul Phillips :
>>>>>>>>>> The inner object is lifted.
>>>>>>>>>>
>>>>>>>>>> scala> Outer$Inner$.MODULE$.c
>>>>>>>>>> res0: Int = 1
>>>>>>>>>>
>>>>>>>>>> Or in java:
>>>>>>>>>>
>>>>>>>>>>  Outer$Inner$.MODULE$.c()
>>>>>>>>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>>>>>>>>
>>>>>>>>> Is there any plan to improve the syntax?
>>>>>>>> ?? This question seems somewhat misleading to me...
>>>>>>>>
>>>>>>>> Scalac is IMHO not primarily a Java code generator.
>>>>>>>>
>>>>>>>> AFAIU Scala compiles by mapping the language constructs
>>>> to the JVM
>>>>>>>> concepts, and when trying to access that from Java you certainly
>>>>>>>> become aware of that mapping results.
>>>>>>>>
>>>>>>>> So "improving the syntax" would imply remodeling the way
>>>> Scala maps
>>>>>>>> to the JVM which for me seems to be a very deep impact.
>>>>>>>>
>>>>>>>> KR
>>>>>>>> Det
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>

On Tue, 2009-10-06 at 13:06 +0200, Viktor Klang wrote:
> "right tool" for me is the one that best fits the requirements :)

You talk as if this was an objective measurement. I am quite confident
that you can find many situations where competent people have a
different opinion on what best is in a given scenario.

> Then that's something that potentially could generate alot of revenue
> for a developer - creating an easy-to-use OpenCL library that
> interfaces with alot of different platforms.

While you wait for a developer to do that, I will let my users benefit
from the performance improvement by changing a few lines of code. :)

> Correctness is more important, but correctness is application
> dependent.
> Using doubles is perfectly fine for many types of
> applications, for
> example.
>
> Doubles and floats are per definition incorrect, since it's impossible
> to represent a lot of numbers using them.

Seems like you ignored what I said. I emphasized application correctness
because that's what matters in the end. If you are producing a set of
rating predictions, you rarely care if something is 4.99995 or 4.99996.

> It still strikes me as kind of retarded that Java has native support
> for them, but not for arbitrary precision decimals. (let's not
> reiterate the BigDecimal discussion ;) )

It may be sad that Java does not have native support for arbitrary
precision decimals, but I am very much glad that it has native support
for doubles. Without it, the JVM would be much less interesting for much
of what I do.

Best,
Ismael

On Tue, Oct 6, 2009 at 4:07 PM, Ismael Juma <mlists@juma.me.uk> wrote:

On Tue, 2009-10-06 at 13:06 +0200, Viktor Klang wrote:
> "right tool" for me is the one that best fits the requirements :)

You talk as if this was an objective measurement. I am quite confident
that you can find many situations where competent people have a
different opinion on what best is in a given scenario.

Therefor you should either be good at argumentation, or be good at measuring things. :)
 

> Then that's something that potentially could generate alot of revenue
> for a developer - creating an easy-to-use OpenCL library that
> interfaces with alot of different platforms.

While you wait for a developer to do that, I will let my users benefit
from the performance improvement by changing a few lines of code. :)

Of course, but the difference in performance between running a Radeon 5870X2 vs running on a quad or octo-thread Intel/AMD cpu is astonishing,
so if you'll have to calculate which is the more appropriate solution.
 

>         Correctness is more important, but correctness is application
>         dependent.
>         Using doubles is perfectly fine for many types of
>         applications, for
>         example.
>
> Doubles and floats are per definition incorrect, since it's impossible
> to represent a lot of numbers using them.

Seems like you ignored what I said. I emphasized application correctness
because that's what matters in the end. If you are producing a set of
rating predictions, you rarely care if something is 4.99995 or 4.99996.

As I said, the best tool for the job...

 

> It still strikes me as kind of retarded that Java has native support
> for them, but not for arbitrary precision decimals. (let's not
> reiterate the BigDecimal discussion ;) )

It may be sad that Java does not have native support for arbitrary
precision decimals, but I am very much glad that it has native support
for doubles. Without it, the JVM would be much less interesting for much
of what I do.

As stated above ;)
 

Best,
Ismael

Warm regards,
--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

On Tue, 2009-10-06 at 16:17 +0200, Viktor Klang wrote:
> Therefor you should either be good at argumentation, or be good at
> measuring things. :)

Such low ambitions. ;) Why settle for "either" when you can go for
"both"? In any case, I'll let you keep your black and white world and
I'll keep my shade of greys one. :)

> Of course, but the difference in performance between running a Radeon
> 5870X2 vs running on a quad or octo-thread Intel/AMD cpu is
> astonishing,
> so if you'll have to calculate which is the more appropriate solution.

And the difference in terms of work to achieve one versus the other is
also astonishing (in one case a few lines of code, in another a whole
new hosting solution).

By the way, I should mention that I am not even sure what your point is
at this stage. On one side, you say that "correctness is more important
than speed of execution" and that "doubles and floats are per definition
incorrect" and in the other you recommend OpenCL where even double
precision is optional.

I'll say what my point is, it's useful to write numeric code in Scala
that runs as fast as possible in the JVM. Today, this is possible, but
more cumbersome than it has to be and I am happy that there is work
being done to improve the situation. This is good enough for many
people.

OpenCL is an interesting solution for the ones who are looking for even
faster performance and have (or can acquire) the right hardware.

Best,
Ismael

On Tue, Oct 6, 2009 at 4:33 PM, Ismael Juma <mlists@juma.me.uk> wrote:

On Tue, 2009-10-06 at 16:17 +0200, Viktor Klang wrote:
> Therefor you should either be good at argumentation, or be good at
> measuring things. :)

Such low ambitions. ;) Why settle for "either" when you can go for
"both"? In any case, I'll let you keep your black and white world and
I'll keep my shade of greys one. :)

The costs of doing both has also to be estimated :)
 

> Of course, but the difference in performance between running a Radeon
> 5870X2 vs running on a quad or octo-thread Intel/AMD cpu is
> astonishing,
> so if you'll have to calculate which is the more appropriate solution.

And the difference in terms of work to achieve one versus the other is
also astonishing (in one case a few lines of code, in another a whole
new hosting solution).

Absolutely, but my point is that it needs to be on a case-to-case-basis
 

By the way, I should mention that I am not even sure what your point is
at this stage. On one side, you say that "correctness is more important
than speed of execution" and that "doubles and floats are per definition
incorrect" and in the other you recommend OpenCL where even double
precision is optional.

I could have said CUDA or Stream but I chose the open standard, sorry, my bad.
 

I'll say what my point is, it's useful to write numeric code in Scala
that runs as fast as possible in the JVM. Today, this is possible, but
more cumbersome than it has to be and I am happy that there is work
being done to improve the situation. This is good enough for many
people.

Agreed
 

OpenCL is an interesting solution for the ones who are looking for even
faster performance and have (or can acquire) the right hardware.

Best,
Ismael

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

Yes, I meant the syntax you need to use from Java.

On Tue, Oct 6, 2009 at 3:40 AM, Detering Dirk wrote:
>> -----Original Message-----
>> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>>
>> It means adding static forwarding methods, for more
>> Java-friendly APIs.
>
> Ah, ok, then the question was misleading in another way :-).
> Syntax and API made a difference to me.
>
> Then it arouses the general question of keeping the
> mapping results as lean as possible or bloating it
> up with convenience elements for the sake of most
> possible Java interop, even if they will be used
> seldom to never in a specific project.
> I.e.: what priority has the Java -> Scala interoperability
> in the eyes of the Scala designers and the Scala users?
>
> My spontaneous answer would be: Interop is on the JVM
> level, not the Java-level. As long as anything is possible,
> it must not be convenient in this regard.
> Either one can explicitly target the Scala API to Java
> usability (avoid scala-isms), or one can create an access
> layer to the Scala part (encapsulate/hide the annoyance).
>
> Just my 2ct
> Det
>
>
>>
>> -------------------------------------
>> Detering Dirk wrote:
>>
>> > 2009/10/5 Paul Phillips :
>> > > The inner object is lifted.
>> > >
>> > > scala> Outer$Inner$.MODULE$.c
>> > > res0: Int = 1
>> > >
>> > > Or in java:
>> > >
>> > >  Outer$Inner$.MODULE$.c()
>>
>> > From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
>> >
>> > Is there any plan to improve the syntax?
>>
>> ?? This question seems somewhat misleading to me...
>>
>> Scalac is IMHO not primarily a Java code generator.
>>
>> AFAIU Scala compiles by mapping the language constructs to
>> the JVM concepts, and when trying to access that from Java
>> you certainly become aware of that mapping results.
>>
>> So "improving the syntax" would imply remodeling the way
>> Scala maps to the JVM which for me seems to be a very deep impact.
>>
>> KR
>> Det
>>
>>
>