General questions

478 views
Skip to first unread message

Tim Ringenbach

unread,
Feb 2, 2013, 10:13:41 PM2/2/13
to scala...@googlegroups.com
Hi,
I found out about this project via a reddit post the other day: http://www.reddit.com/r/programming/comments/17rs7t/compiling_scala_to_llvm/
At least one guy in the reddit comments claims the project is dead, but I'm hoping to hear otherwise.

I was also curious how this approach compares to using gcj. At least one guy has a tutorial on that subject:  http://www.iulidragos.org/?p=23 though apparently it doesn't really work. Also, I wonder why you can't just use gcj to compile the Java classes you need to native code in order to get all of the Scala standard library to compile. But I'm sure it's not that simple. 

Also, it was my understanding that gcj was never able to make native ahead of time Java as fast as JITted Java. It sounds like you think you can make native Scala faster than running on the JVM.

Thanks,
--Tim

Jon Harrop

unread,
Feb 3, 2013, 7:25:04 AM2/3/13
to Tim Ringenbach, scala...@googlegroups.com
> At least one guy in the reddit comments claims the project is dead, but
I'm hoping to hear otherwise.

Your post appears to be the third in the history of this project and is the
first one after 6 months of silence.

> I was also curious how this approach compares to using gcj. At least one
guy has a tutorial on that subject:  http://www.iulidragos.org/?p=23 though
apparently it doesn't really work. Also, I wonder why you can't just use gcj
to compile the Java classes you need to native code in order to get all of
the Scala standard library to compile. But I'm sure it's not that simple. 

IME gcj is so buggy as to be completely useless.

> It sounds like you think you can make native Scala faster than running on
the JVM.

The JVM’s performance is crippled by lack of value types, lack of reified
generics and lack of tail call optimization so it wouldn’t be hard to beat
the performance of the JVM provided you’re willing to sacrifice some
backward compatibility. From what I hear, the FFI could be a lot faster too.

Cheers,
Jon.


Konstantin Kowalski

unread,
Feb 3, 2013, 7:28:22 AM2/3/13
to scala...@googlegroups.com
Hello,
I just found this project via reddit too. I think it may be possible to do more optimization if you compile Scala code itself, without the middleman Java. But as you pointed out, it may not be a worthwhile trade-off, since you do not have the access to all the Java libraries.

Geoff Reedy

unread,
Feb 10, 2013, 5:01:16 PM2/10/13
to Jon Harrop, Tim Ringenbach, scala...@googlegroups.com
On Sun, Feb 03, 2013 at 12:25:04PM -0000, Jon Harrop said
> > At least one guy in the reddit comments claims the project is dead,
> > but I'm hoping to hear otherwise.
>
> Your post appears to be the third in the history of this project and
> is the first one after 6 months of silence.

So, it's not dead but there's (currently) noone working on it besides me
and my time for it is very limited (to barely more than zero over the
last year). I'm hopeful that I'll be able to find more time, hopefully
around summer. That said, if anyone is interested in working on it, I'm
more than happy to have the help. I do promise to make some time to work
with potential contributors, but as you can see my latency can be pretty
bad at times.

> > I was also curious how this approach compares to using gcj. At least
> > one guy has a tutorial on that subject:
> >  http://www.iulidragos.org/?p=23 though apparently it doesn't really
> > work. Also, I wonder why you can't just use gcj to compile the Java
> > classes you need to native code in order to get all of the Scala
> > standard library to compile. But I'm sure it's not that simple. 
>
> IME gcj is so buggy as to be completely useless.

I'm pretty sure that scala with gcj will work even less well than it did
then.

>
> > It sounds like you think you can make native Scala faster than
> > running on the JVM.
>
> The JVM’s performance is crippled by lack of value types, lack of
> reified generics and lack of tail call optimization so it wouldn’t be
> hard to beat the performance of the JVM provided you’re willing to
> sacrifice some backward compatibility. From what I hear, the FFI could
> be a lot faster too.

Yes, this what I'm interested in and part of why I started this effort.
There are lots of ways that the JVM constrains the implementation of
scala language features and I want to see how they might be implemented
more directly. In the long run this will probably mean generating code
from trees and not ICode since ICode is pretty close to JVM bytecode and
assumes many of its shortcomings.

-- Geoff

Brandon Lewis

unread,
Mar 28, 2013, 2:09:03 PM3/28/13
to scala...@googlegroups.com, Jon Harrop, Tim Ringenbach
I'd be interested in helping, but:

1) Not much experience with compilers
2) Don't really know scala.

I'd probably need too much hand-holding at present. But maybe down the road?
Reply all
Reply to author
Forward
0 new messages