Re: Monad Presentation

No, Ben started the group, I recorded it, there has been some great
presentations unfortunately we haven't recorded them I was hoping we could
and we had a partial success (the second one didn't sound well) 

Randall Schulz wrote:
> 
> On Friday October 30 2009, Ben Hutchison wrote:
>> On Sat, Oct 31, 2009 at 3:45 PM, Randall R Schulz <rschulz <at> sonic.net> 
> wrote:
>> > Anyway, I was wondering if there were any slides to go with the
>> > talk?
>>
>> Yes, I guess it would be hard to follow without these slides to refer
>> to:
>>
>> http://scala-melb.googlegroups.com/web/scala_monads.pdf
> 
> Thank you!
> 
> By the way, was it you who posted the earlier messages as "Randin?"
> 
> 
>> -Ben
> 
> 
> Randall Schulz
> 
> 

Scala on Android - Performance

Hey all,

I'm a complete newbie to programming on the Scala platform, however I've
been working on testing the performance of Scala on the Android platform. I
have started a project on github which can be found at
http://github.com/akshaydashrath/Scala-Performance-Testing-Android,
basically what I'm testing is the performance of a quick sort as well as a
binary search on a large number of elements present in a list first with
Scala and then with Java. I expected results to favour Scala but I'm getting
worse off performance with Scala then with Java, some of the initial results
are given below. Since I have little knowledge with the way scala code is
compiled into byte code I thought maybe someone could explain this for me,
Is the compilation of code designed to make best use of VM features such  as
JIT and adaptive compilation, this would explain the lack of performance on
the Dalvik VM as it has none such optimisations. Any help would be most
appreciated as the results of this study will be presented at Droidcon
London and any help will be duly noted and credit provided in the
presentation.

Results:

Scala:
Sorting = 1219msec
Searching time = 37msec
Total instructions executed: 1397082
Method invocations: 183121

Java:
Sorting = 343msec

Re: Scala on Android - Performance

ARM CPUs

ARM CPUs are attractiong some attention now.

PDAs a la SmartDevices SmartQ7
phones a la OpenMoko
SmartBooks, that are much told upon

However it seems there is no official JRE's for ARM.

And unofficials are feature-cut and usually use ClassPath or other  
non-standard RTL.

Since Scala tends to stretch the bounds of JRE it begs a question if  
Scala-written apps will work there.

Did anyone experienced with Scala on ARM and which Java runtime is better  
suited then ?

--

-- 
Используется революционный почтовый клиент
браузера Opera:  
http://www.opera.com/mail/

Re: ARM CPUs

I have tested one of our apps using one of the Classpath-based JREs
(Cacao), on an ARM device, and it worked fine.  This was a
command-line app.  I had some issues because it was a command-line app
that called into [broken] libs that required GUI toolkits (though
without displaying anything), so I had to install the GTK libs, but
that wasn't too painful.  With a Sun VM I could have told it to use
the motif peers instead.

My colleague who uses ARM devices a lot, but not Java (or Scala)
reports that OpenEmbedded, which they are planning to use shortly, has
OpenJDK bundled.  We've had issues with our apps on OpenJDK before,
but I expect that's a bit more promising for running arbitrary
programs on.

2009/11/1 Arioch <the_Arioch <at> nm.ru>:
> ARM CPUs are attractiong some attention now.
>
> PDAs a la SmartDevices SmartQ7
> phones a la OpenMoko
> SmartBooks, that are much told upon
>
> However it seems there is no official JRE's for ARM.
>
> And unofficials are feature-cut and usually use ClassPath or other
> non-standard RTL.
>
> Since Scala tends to stretch the bounds of JRE it begs a question if
> Scala-written apps will work there.
>
> Did anyone experienced with Scala on ARM and which Java runtime is better
> suited then ?
>
> --
> Используется революционный почтовый клиент
браузера Opera:
> http://www.opera.com/mail/
>
>

--

-- 
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson <at> gmail.com
Google Wave: ricky.clarkson <at> googlewave.com

Re: ARM CPUs

Re: Scala on Android - Performance

On Sun, Nov 1, 2009 at 9:52 AM, akshaydashrath <akshaydashrath <at> gmail.com> wrote:
>
> Hey all,
>
> I'm a complete newbie to programming on the Scala platform, however I've
> been working on testing the performance of Scala on the Android platform. I
> have started a project on github which can be found at
> http://github.com/akshaydashrath/Scala-Performance-Testing-Android,
> basically what I'm testing is the performance of a quick sort as well as a
> binary search on a large number of elements present in a list first with
> Scala and then with Java. I expected results to favour Scala but I'm getting
> worse off performance with Scala then with Java, some of the initial results
> are given below. Since I have little knowledge with the way scala code is
> compiled into byte code I thought maybe someone could explain this for me,
> Is the compilation of code designed to make best use of VM features such  as
> JIT and adaptive compilation, this would explain the lack of performance on
> the Dalvik VM as it has none such optimisations. Any help would be most
> appreciated as the results of this study will be presented at Droidcon
> London and any help will be duly noted and credit provided in the
> presentation.
>
> Results:
>
> Scala:
> Sorting = 1219msec
> Searching time = 37msec
> Total instructions executed: 1397082
> Method invocations: 183121
>
> Java:
> Sorting = 343msec
> Searching time = 4msec
> Total instructions executed: 895190
> Method invocations: 75442
>

At least in one place you're comparing data structures and algorithms
but not languages. Your scala implementation of quicksort is the sort
of "canonical" quicksort you see for functional languages, but it uses
Lists and not Arrays, like your Java implementation does. In
particular, your scala partition logic makes three O(n) passes over
each list (because indexing into a list takes time linear in the
index). Your java quicksort, by comparison, is normal imperative
quicksort, which partitions the Array(!) in a single pass.

By way of comparison, the scala library implementation of sort would
copy things to an Array, and then invoke a standard array sort
algorithm, and then copy them back into the expected result type. (And
I'm guessing that if the underlying data structure is already an
Array, Scala is usually smart enough to just sort that array).

So yes, if you write slow code, it will be slow.

-- David

> Thank you,
>
> Regards,
>
> Akshay
>
>
> --
> View this message in context: http://old.nabble.com/Scala-on-Android---Performance-tp26149143p26149143.html
> Sent from the Scala mailing list archive at Nabble.com.
>
>

Re: ARM CPUs

  Back when Sharp SL5000 PDA's (ARM powered) were the developer's rage,
there was a fairly good JVM running on it.  I forget the name, but as I 
recall, it did
floating point emu, but was still rather fast.  It was >ME, <SE, I don't
know how it would be categorized.

But as far as "no official" version, did you see this?  1.6u10+.  Can't 
beat that.  :)
http://java.sun.com/javase/embedded/system_requirements.jsp

bob

On 11/1/2009 3:56 PM, Arioch wrote:
> ARM CPUs are attractiong some attention now.
>
> PDAs a la SmartDevices SmartQ7
> phones a la OpenMoko
> SmartBooks, that are much told upon
>
> However it seems there is no official JRE's for ARM.
>
> And unofficials are feature-cut and usually use ClassPath or other 
> non-standard RTL.
>
> Since Scala tends to stretch the bounds of JRE it begs a question if 
> Scala-written apps will work there.
>
> Did anyone experienced with Scala on ARM and which Java runtime is 
> better suited then ?
>

Can anyone grok this stack-trace

Trying to run my compiler plugin from eclipse, and:

Exception in thread "main" java.lang.NoClassDefFoundError: scala/collection/Seq
	at java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
	at java.lang.Class.getConstructor0(Class.java:2699)
	at java.lang.Class.getConstructor(Class.java:1657)
	at scala.tools.nsc.plugins.Plugin$.instantiate(Plugin.scala:152)
	at scala.tools.nsc.plugins.Plugins$$anonfun$loadRoughPluginsList$1.apply(Plugins.scala:33)
	at scala.tools.nsc.plugins.Plugins$$anonfun$loadRoughPluginsList$1.apply(Plugins.scala:32)
	at scala.collection.generic.TraversableTemplate$$anonfun$map$1.apply(TraversableTemplate.scala:211)
	at scala.collection.generic.TraversableTemplate$$anonfun$map$1.apply(TraversableTemplate.scala:211)
	at scala.collection.generic.LinearSequenceTemplate$class.foreach(LinearSequenceTemplate.scala:82)
	at scala.collection.immutable.List.foreach(List.scala:27)
	at scala.collection.generic.TraversableTemplate$class.map(TraversableTemplate.scala:211)
	at scala.collection.immutable.List.map(List.scala:27)
	at scala.tools.nsc.plugins.Plugins$class.loadRoughPluginsList(Plugins.scala:32)
	at scala.tools.nsc.Global.loadRoughPluginsList(Global.scala:35)
	at scala.tools.nsc.plugins.Plugins$class.roughPluginsList(Plugins.scala:42)
	at scala.tools.nsc.Global.roughPluginsList(Global.scala:35)
	at scala.tools.nsc.plugins.Plugins$class.loadPlugins(Plugins.scala:94)
	at scala.tools.nsc.Global.loadPlugins(Global.scala:35)
	at scala.tools.nsc.plugins.Plugins$class.plugins(Plugins.scala:125)
	at scala.tools.nsc.Global.plugins(Global.scala:35)
	at scala.tools.nsc.plugins.Plugins$class.computePluginPhases(Plugins.scala:142)
	at scala.tools.nsc.Global.computePluginPhases(Global.scala:35)
	at scala.tools.nsc.Global.computePhaseDescriptors(Global.scala:622)
	at scala.tools.nsc.Global.phaseDescriptors(Global.scala:634)
	at scala.tools.nsc.Global$Run.<init>(Global.scala:689)
	at scala.tools.nsc.Main$.process(Main.scala:90)
	at scala.tools.nsc.Main$.main(Main.scala:105)
	at scala.tools.nsc.Main.main(Main.scala)

I've come back to this after a 3-week hiatus of not following the 2.8
trunk and eclipse nightly builds, so almost anything could have gone
wrong in the period.
I'm also NOT using the classpath container as provided by the eclipse
plugin, instead I've explicitly added the compiler, dbc, library and
swing jars from the latest SVN build.

Is this just a temporary glitch in trunk, or do I need to be taking a
deeper look at my configuration?

Re: Can anyone grok this stack-trace