[Java] Is the effort available?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Java] Is the effort available?

Tyler MacLeod-2
Hi all,

I was wondering if the current effort to compile to a Java target is available in a public repo somewhere. I don't really know OCaml, but I'd like to see the progress.

Thank you,
Tyler

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Raoul Duke
since ocaml can compile to the jvm, maybe just have haxe spit out
ocaml ha ha oy veh.

On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod <[hidden email]> wrote:

> Hi all,
> I was wondering if the current effort to compile to a Java target is
> available in a public repo somewhere. I don't really know OCaml, but I'd
> like to see the progress.
> Thank you,
> Tyler
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Baluta Cristian
why generate ocaml if java is much more similar?

On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
since ocaml can compile to the jvm, maybe just have haxe spit out
ocaml ha ha oy veh.

On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod <[hidden email]> wrote:
> Hi all,
> I was wondering if the current effort to compile to a Java target is
> available in a public repo somewhere. I don't really know OCaml, but I'd
> like to see the progress.
> Thank you,
> Tyler
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Cauê W.
I think he's talking about the java haXe target.

If that's the case, I'm sorry but it's still not available. I intend to release it as soon as it's available for beta testing.
If you want to hear more about the new targets, you could show up at the haXe meeting on May! : )

By the way, don't worry the targets will have the same license as HaXe itself. But it's still not available right now.

I hope you understand,
Caue

2011/3/30 Baluta Cristian <[hidden email]>
why generate ocaml if java is much more similar?


On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
since ocaml can compile to the jvm, maybe just have haxe spit out
ocaml ha ha oy veh.

On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod <[hidden email]> wrote:
> Hi all,
> I was wondering if the current effort to compile to a Java target is
> available in a public repo somewhere. I don't really know OCaml, but I'd
> like to see the progress.
> Thank you,
> Tyler
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Jordo Odroj
Caue,

In your initial findings, what have you found the performance
characteristics to be?
I'm really excited about the Java target.

Jordo

On Wed, Mar 30, 2011 at 3:31 AM, Cauê Waneck <[hidden email]> wrote:

> I think he's talking about the java haXe target.
> If that's the case, I'm sorry but it's still not available. I intend to
> release it as soon as it's available for beta testing.
> If you want to hear more about the new targets, you could show up at the
> haXe meeting on May! : )
> By the way, don't worry the targets will have the same license as HaXe
> itself. But it's still not available right now.
> I hope you understand,
> Caue
> 2011/3/30 Baluta Cristian <[hidden email]>
>>
>> why generate ocaml if java is much more similar?
>>
>> On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
>>>
>>> since ocaml can compile to the jvm, maybe just have haxe spit out
>>> ocaml ha ha oy veh.
>>>
>>> On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod <[hidden email]>
>>> wrote:
>>> > Hi all,
>>> > I was wondering if the current effort to compile to a Java target is
>>> > available in a public repo somewhere. I don't really know OCaml, but
>>> > I'd
>>> > like to see the progress.
>>> > Thank you,
>>> > Tyler
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>> >
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>>
>> --
>> Băluță Cristian
>> http://ralcr.com
>> http://imagin.ro
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Cauê W.
Hey Jordo!

Well, tbh most of the optimizations I've only applied to c# by now, since I've started to refactor the code. But most of them do also apply to java. It's also harder to come up with a good microbenchmark on Java since it really does well in optimizing virtual calls, so sometimes you think that the performance is awesome, but it's just that the vm has inlined most of your code and unwrapped a loop.

Well, anyway, what I can assure you is that:
- Fully typed haXe code will perform as if it was native java
- I am studying a concise haxe.rtti.Generic implementation for Java that will allow haXe Arrays and Hash to perform better than ArrayList and Hashtable equivalents, and make haXe array performance comparable to Java's native array (fixed size)
- HaXe reflection (and anonymous types) is some orders of magnitude faster than Java's builtin reflection. I've also made some optimizations on C# that must also be applied to java (not done). This is not much considering the poor Java/CLR reflection performance, but applying those new optimizations should make it as fast as possible compared to fully typed code
- closures will perform almost as fast as virtual functions.

Cheers!

2011/4/2 Jordo Odroj <[hidden email]>
Caue,

In your initial findings, what have you found the performance
characteristics to be?
I'm really excited about the Java target.

Jordo

On Wed, Mar 30, 2011 at 3:31 AM, Cauê Waneck <[hidden email]> wrote:
> I think he's talking about the java haXe target.
> If that's the case, I'm sorry but it's still not available. I intend to
> release it as soon as it's available for beta testing.
> If you want to hear more about the new targets, you could show up at the
> haXe meeting on May! : )
> By the way, don't worry the targets will have the same license as HaXe
> itself. But it's still not available right now.
> I hope you understand,
> Caue
> 2011/3/30 Baluta Cristian <[hidden email]>
>>
>> why generate ocaml if java is much more similar?
>>
>> On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
>>>
>>> since ocaml can compile to the jvm, maybe just have haxe spit out
>>> ocaml ha ha oy veh.
>>>
>>> On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod <[hidden email]>
>>> wrote:
>>> > Hi all,
>>> > I was wondering if the current effort to compile to a Java target is
>>> > available in a public repo somewhere. I don't really know OCaml, but
>>> > I'd
>>> > like to see the progress.
>>> > Thank you,
>>> > Tyler
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>> >
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>>
>> --
>> Băluță Cristian
>> http://ralcr.com
>> http://imagin.ro
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Franco Ponticelli
Sounds amazing!

On Sat, Apr 2, 2011 at 10:42 PM, Cauê Waneck <[hidden email]> wrote:
Hey Jordo!

Well, tbh most of the optimizations I've only applied to c# by now, since I've started to refactor the code. But most of them do also apply to java. It's also harder to come up with a good microbenchmark on Java since it really does well in optimizing virtual calls, so sometimes you think that the performance is awesome, but it's just that the vm has inlined most of your code and unwrapped a loop.

Well, anyway, what I can assure you is that:
- Fully typed haXe code will perform as if it was native java
- I am studying a concise haxe.rtti.Generic implementation for Java that will allow haXe Arrays and Hash to perform better than ArrayList and Hashtable equivalents, and make haXe array performance comparable to Java's native array (fixed size)
- HaXe reflection (and anonymous types) is some orders of magnitude faster than Java's builtin reflection. I've also made some optimizations on C# that must also be applied to java (not done). This is not much considering the poor Java/CLR reflection performance, but applying those new optimizations should make it as fast as possible compared to fully typed code
- closures will perform almost as fast as virtual functions.

Cheers!

2011/4/2 Jordo Odroj <[hidden email]>
Caue,

In your initial findings, what have you found the performance
characteristics to be?
I'm really excited about the Java target.

Jordo

On Wed, Mar 30, 2011 at 3:31 AM, Cauê Waneck <[hidden email]> wrote:
> I think he's talking about the java haXe target.
> If that's the case, I'm sorry but it's still not available. I intend to
> release it as soon as it's available for beta testing.
> If you want to hear more about the new targets, you could show up at the
> haXe meeting on May! : )
> By the way, don't worry the targets will have the same license as HaXe
> itself. But it's still not available right now.
> I hope you understand,
> Caue
> 2011/3/30 Baluta Cristian <[hidden email]>
>>
>> why generate ocaml if java is much more similar?
>>
>> On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
>>>
>>> since ocaml can compile to the jvm, maybe just have haxe spit out
>>> ocaml ha ha oy veh.
>>>
>>> On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod <[hidden email]>
>>> wrote:
>>> > Hi all,
>>> > I was wondering if the current effort to compile to a Java target is
>>> > available in a public repo somewhere. I don't really know OCaml, but
>>> > I'd
>>> > like to see the progress.
>>> > Thank you,
>>> > Tyler
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>> >
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>>
>> --
>> Băluță Cristian
>> http://ralcr.com
>> http://imagin.ro
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Jordo Odroj
Agree - this is great. Thanks for your effort!

On Sat, Apr 2, 2011 at 3:25 PM, Franco Ponticelli
<[hidden email]> wrote:

> Sounds amazing!
>
> On Sat, Apr 2, 2011 at 10:42 PM, Cauê Waneck <[hidden email]> wrote:
>>
>> Hey Jordo!
>> Well, tbh most of the optimizations I've only applied to c# by now, since
>> I've started to refactor the code. But most of them do also apply to java.
>> It's also harder to come up with a good microbenchmark on Java since it
>> really does well in optimizing virtual calls, so sometimes you think that
>> the performance is awesome, but it's just that the vm has inlined most of
>> your code and unwrapped a loop.
>> Well, anyway, what I can assure you is that:
>> - Fully typed haXe code will perform as if it was native java
>> - I am studying a concise haxe.rtti.Generic implementation for Java that
>> will allow haXe Arrays and Hash to perform better than ArrayList and
>> Hashtable equivalents, and make haXe array performance comparable to Java's
>> native array (fixed size)
>> - HaXe reflection (and anonymous types) is some orders of magnitude faster
>> than Java's builtin reflection. I've also made some optimizations on C# that
>> must also be applied to java (not done). This is not much considering the
>> poor Java/CLR reflection performance, but applying those new optimizations
>> should make it as fast as possible compared to fully typed code
>> - closures will perform almost as fast as virtual functions.
>> Cheers!
>> 2011/4/2 Jordo Odroj <[hidden email]>
>>>
>>> Caue,
>>>
>>> In your initial findings, what have you found the performance
>>> characteristics to be?
>>> I'm really excited about the Java target.
>>>
>>> Jordo
>>>
>>> On Wed, Mar 30, 2011 at 3:31 AM, Cauê Waneck <[hidden email]> wrote:
>>> > I think he's talking about the java haXe target.
>>> > If that's the case, I'm sorry but it's still not available. I intend to
>>> > release it as soon as it's available for beta testing.
>>> > If you want to hear more about the new targets, you could show up at
>>> > the
>>> > haXe meeting on May! : )
>>> > By the way, don't worry the targets will have the same license as HaXe
>>> > itself. But it's still not available right now.
>>> > I hope you understand,
>>> > Caue
>>> > 2011/3/30 Baluta Cristian <[hidden email]>
>>> >>
>>> >> why generate ocaml if java is much more similar?
>>> >>
>>> >> On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
>>> >>>
>>> >>> since ocaml can compile to the jvm, maybe just have haxe spit out
>>> >>> ocaml ha ha oy veh.
>>> >>>
>>> >>> On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod
>>> >>> <[hidden email]>
>>> >>> wrote:
>>> >>> > Hi all,
>>> >>> > I was wondering if the current effort to compile to a Java target
>>> >>> > is
>>> >>> > available in a public repo somewhere. I don't really know OCaml,
>>> >>> > but
>>> >>> > I'd
>>> >>> > like to see the progress.
>>> >>> > Thank you,
>>> >>> > Tyler
>>> >>> > --
>>> >>> > haXe - an open source web programming language
>>> >>> > http://haxe.org
>>> >>> >
>>> >>>
>>> >>> --
>>> >>> haXe - an open source web programming language
>>> >>> http://haxe.org
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Băluță Cristian
>>> >> http://ralcr.com
>>> >> http://imagin.ro
>>> >>
>>> >> --
>>> >> haXe - an open source web programming language
>>> >> http://haxe.org
>>> >
>>> >
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>> >
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Justin Donaldson-3
In reply to this post by Cauê W.
This all sounds fantastic.  I thought for sure reflection would be a huge obstacle, congrats if you have it licked.  I'd really love to hear a trip report of the process, as well as hearing about any warts or problems that might require workarounds.

-Justin

On Sat, Apr 2, 2011 at 2:42 PM, Cauê Waneck <[hidden email]> wrote:
Hey Jordo!

Well, tbh most of the optimizations I've only applied to c# by now, since I've started to refactor the code. But most of them do also apply to java. It's also harder to come up with a good microbenchmark on Java since it really does well in optimizing virtual calls, so sometimes you think that the performance is awesome, but it's just that the vm has inlined most of your code and unwrapped a loop.

Well, anyway, what I can assure you is that:
- Fully typed haXe code will perform as if it was native java
- I am studying a concise haxe.rtti.Generic implementation for Java that will allow haXe Arrays and Hash to perform better than ArrayList and Hashtable equivalents, and make haXe array performance comparable to Java's native array (fixed size)
- HaXe reflection (and anonymous types) is some orders of magnitude faster than Java's builtin reflection. I've also made some optimizations on C# that must also be applied to java (not done). This is not much considering the poor Java/CLR reflection performance, but applying those new optimizations should make it as fast as possible compared to fully typed code
- closures will perform almost as fast as virtual functions.

Cheers!

2011/4/2 Jordo Odroj <[hidden email]>
Caue,

In your initial findings, what have you found the performance
characteristics to be?
I'm really excited about the Java target.

Jordo

On Wed, Mar 30, 2011 at 3:31 AM, Cauê Waneck <[hidden email]> wrote:
> I think he's talking about the java haXe target.
> If that's the case, I'm sorry but it's still not available. I intend to
> release it as soon as it's available for beta testing.
> If you want to hear more about the new targets, you could show up at the
> haXe meeting on May! : )
> By the way, don't worry the targets will have the same license as HaXe
> itself. But it's still not available right now.
> I hope you understand,
> Caue
> 2011/3/30 Baluta Cristian <[hidden email]>
>>
>> why generate ocaml if java is much more similar?
>>
>> On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
>>>
>>> since ocaml can compile to the jvm, maybe just have haxe spit out
>>> ocaml ha ha oy veh.
>>>
>>> On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod <[hidden email]>
>>> wrote:
>>> > Hi all,
>>> > I was wondering if the current effort to compile to a Java target is
>>> > available in a public repo somewhere. I don't really know OCaml, but
>>> > I'd
>>> > like to see the progress.
>>> > Thank you,
>>> > Tyler
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>> >
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>>
>> --
>> Băluță Cristian
>> http://ralcr.com
>> http://imagin.ro
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Jordo Odroj
In reply to this post by Cauê W.
I just thought of a question: When you said "fully typed", I'm became
concerned about how the code that I (personally) tend to write would
perform. I tend to not use a lot of classes and interfaces, and
instead use many typeDefs and rely on the structural subtyping system
of haxe.
How are you going about implementing typedefs? Are you turning each of
them into interface (in which case I can imagine my programs will be
quite fast as you have said).

For example, in:
typedef JordoType = {x:Int, y:String };
->I could imagine you make a java interface for this.

Then when I instantiate an object of type JordoType:
var someThing : JordoType = {x:3423, y:"cant wait for the java target!"};
-> I could imagine you make a java "anonymous class"

Is this how you are going about it (with Java anonymous classes)?
If so, it seems that, yes, we can get insane speed by relying on Java
paradigms that very naturally fit the Haxe type system. :)

But then what do we do about structural type inference?
Suppose that you have a function that accepts a JordoType
pub fun myFunction(jt: JordoType) {

}

At some other point in the code: I might have:
typedef CaueType = {x:Int, y:String, z:Bool};
var someOtherThing : CaueType = {x:44532, y:"Heylo!", z:true};

In haxe, I can pass the someOtherThing to myFunction() because the
structural type system infers that CaueType is a subtype of JordoType.
But if we implemented "someOtherThing : CaueType = ..." using java
anonymous Classes, then how can we also ensure that I can pass an
instance of CaueType to myFunc(jt: JordoType)?

It seems like, for each new type declaration, we could find *all*
possible declared types (or inferred) and ensure that every instance
is properly is annotated as an anonymous Class of all the interfaces
it matches as a subtype. That way, we could not have to resort to
using reflection (and other slow means).

(Please humor me, as I have no idea about how to implement a target,
but I'm trying to learn what is involved in the process so that I can
eventually contribute (to the java target, ideally).

Jordo

On Sat, Apr 2, 2011 at 2:42 PM, Cauê Waneck <[hidden email]> wrote:

> Hey Jordo!
> Well, tbh most of the optimizations I've only applied to c# by now, since
> I've started to refactor the code. But most of them do also apply to java.
> It's also harder to come up with a good microbenchmark on Java since it
> really does well in optimizing virtual calls, so sometimes you think that
> the performance is awesome, but it's just that the vm has inlined most of
> your code and unwrapped a loop.
> Well, anyway, what I can assure you is that:
> - Fully typed haXe code will perform as if it was native java
> - I am studying a concise haxe.rtti.Generic implementation for Java that
> will allow haXe Arrays and Hash to perform better than ArrayList and
> Hashtable equivalents, and make haXe array performance comparable to Java's
> native array (fixed size)
> - HaXe reflection (and anonymous types) is some orders of magnitude faster
> than Java's builtin reflection. I've also made some optimizations on C# that
> must also be applied to java (not done). This is not much considering the
> poor Java/CLR reflection performance, but applying those new optimizations
> should make it as fast as possible compared to fully typed code
> - closures will perform almost as fast as virtual functions.
> Cheers!
> 2011/4/2 Jordo Odroj <[hidden email]>
>>
>> Caue,
>>
>> In your initial findings, what have you found the performance
>> characteristics to be?
>> I'm really excited about the Java target.
>>
>> Jordo
>>
>> On Wed, Mar 30, 2011 at 3:31 AM, Cauê Waneck <[hidden email]> wrote:
>> > I think he's talking about the java haXe target.
>> > If that's the case, I'm sorry but it's still not available. I intend to
>> > release it as soon as it's available for beta testing.
>> > If you want to hear more about the new targets, you could show up at the
>> > haXe meeting on May! : )
>> > By the way, don't worry the targets will have the same license as HaXe
>> > itself. But it's still not available right now.
>> > I hope you understand,
>> > Caue
>> > 2011/3/30 Baluta Cristian <[hidden email]>
>> >>
>> >> why generate ocaml if java is much more similar?
>> >>
>> >> On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]> wrote:
>> >>>
>> >>> since ocaml can compile to the jvm, maybe just have haxe spit out
>> >>> ocaml ha ha oy veh.
>> >>>
>> >>> On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod
>> >>> <[hidden email]>
>> >>> wrote:
>> >>> > Hi all,
>> >>> > I was wondering if the current effort to compile to a Java target is
>> >>> > available in a public repo somewhere. I don't really know OCaml, but
>> >>> > I'd
>> >>> > like to see the progress.
>> >>> > Thank you,
>> >>> > Tyler
>> >>> > --
>> >>> > haXe - an open source web programming language
>> >>> > http://haxe.org
>> >>> >
>> >>>
>> >>> --
>> >>> haXe - an open source web programming language
>> >>> http://haxe.org
>> >>
>> >>
>> >>
>> >> --
>> >> Băluță Cristian
>> >> http://ralcr.com
>> >> http://imagin.ro
>> >>
>> >> --
>> >> haXe - an open source web programming language
>> >> http://haxe.org
>> >
>> >
>> > --
>> > haXe - an open source web programming language
>> > http://haxe.org
>> >
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Cauê W.
Hey! : )

2011/4/2 Jordo Odroj <[hidden email]>
How are you going about implementing typedefs? Are you turning each of
them into interface (in which case I can imagine my programs will be
quite fast as you have said).

So... I've thought a LOT about that, but I haven't come up with a good solution. We -could- think of a way to implement anonymous types as a kind of tuple, but the problem would be that you can't guarantee, but in very special cases, that the anonymous type was actually generated with that kind of tuple in mind. If HaXe had real tuples, that don't depend on the property name, but their declaration order, this could be easily implemented.

Some more complex solutions could be made, something in the line of what javascript v8 does with its "inferred classes" (or something like that), but I think I will leave this one for the future ; )
Anyway, what I've done so far is that I've tried to make reflection to be as fast as possible, so using it isn't a problem. I've done this by
1 - creating specialized containers for basic types, so they don't need to be boxed
2 - having a fast data-structure for acessing dynamic types (Basically I'm performing a binary search in an array)
3 - having the fastest way to compare strings - since our reflection is string-based, we need to have a good way to compare them and still have good performance. I chose (and that's what I said that isn't still implemented on the java target) to implement a <= 30 chars string as 3 int64's. This is done by restricting the possible chars of the string to what's legal in haXe. And this is far the fastest way to compare strings (a full 30-char string comparison actually takes 3 comparisons!). Of course, there is a fallback for > 30 chars names using actual strings.

The cool part about 3 is that the compiler will convert "myDynamicField" in "myDynamicVar.myDynamicField" into the correct 3 int64's representation at compile time, which means that it will be extra fast for when you don't resort on Reflect.field .

Those 3 optimizations are what I could think of to achieve the best performance as possible for the target. Of course, what you said about dynamic interfaces would be great, but they would either depend on a heavy static analysis of what is being compiled (which would surely break when dynamically loading modules). There is also the option to dynamically generate java bytecode, but I'm avoiding that at all costs so the target can be compatible, predictable and not get caught on those permgen garbage collection woes!

There is also an option to require all strings to be interned (like Lua), and then strings hashing and comparing would be much, much faster. But this would either mean that we don't use Java's native string type (not good for compatibility), or use Java's string interning (again, permgen garbage collection woes!)

Oh, there is one last option, which I mentioned eariler, which would require creating anonymous classes/interfaces for each anonymous type, and then when casting between them, add a cast() layer that could take care of boxing the underlying type to the expected anonymous class/interface.
This option seems interesting, but we would really need to think of all the pros and cons of this approach. maybe after its first release ; )
I've decided to refactor the whole code (which was really needed, since it was my first ocaml project, and I wanted to use a strategy pattern to be able to easily setup modules of features for the targets, so in the end it was just a chaotic mess...), so by now I'm working to have it nice and usable for the haXe meeting on May! Will you come there? I'll talk about the implementations with more details + some benchmarks (and hopefully some comparisons with other languages like scala ) ;)

Cheers!
Cauê

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Tarwin Stroh-Spijer
Stupid question, but have you been keeping up with the stuff that Joa Ebert has been doing with JITB (http://blog.joa-ebert.com/2010/08/19/introducing-jitb/). Really interesting SWF > Java converter, with a great NME-like Java layer. Really worth checking out, and hopefully we don't have to duplicate our efforts when we're looking for NME-like layer - he showed it at Geeky by Nature and it's great.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Sun, Apr 3, 2011 at 12:24 PM, Cauê Waneck <[hidden email]> wrote:
Hey! : )

2011/4/2 Jordo Odroj <[hidden email]>
How are you going about implementing typedefs? Are you turning each of
them into interface (in which case I can imagine my programs will be
quite fast as you have said).

So... I've thought a LOT about that, but I haven't come up with a good solution. We -could- think of a way to implement anonymous types as a kind of tuple, but the problem would be that you can't guarantee, but in very special cases, that the anonymous type was actually generated with that kind of tuple in mind. If HaXe had real tuples, that don't depend on the property name, but their declaration order, this could be easily implemented.

Some more complex solutions could be made, something in the line of what javascript v8 does with its "inferred classes" (or something like that), but I think I will leave this one for the future ; )
Anyway, what I've done so far is that I've tried to make reflection to be as fast as possible, so using it isn't a problem. I've done this by
1 - creating specialized containers for basic types, so they don't need to be boxed
2 - having a fast data-structure for acessing dynamic types (Basically I'm performing a binary search in an array)
3 - having the fastest way to compare strings - since our reflection is string-based, we need to have a good way to compare them and still have good performance. I chose (and that's what I said that isn't still implemented on the java target) to implement a <= 30 chars string as 3 int64's. This is done by restricting the possible chars of the string to what's legal in haXe. And this is far the fastest way to compare strings (a full 30-char string comparison actually takes 3 comparisons!). Of course, there is a fallback for > 30 chars names using actual strings.

The cool part about 3 is that the compiler will convert "myDynamicField" in "myDynamicVar.myDynamicField" into the correct 3 int64's representation at compile time, which means that it will be extra fast for when you don't resort on Reflect.field .

Those 3 optimizations are what I could think of to achieve the best performance as possible for the target. Of course, what you said about dynamic interfaces would be great, but they would either depend on a heavy static analysis of what is being compiled (which would surely break when dynamically loading modules). There is also the option to dynamically generate java bytecode, but I'm avoiding that at all costs so the target can be compatible, predictable and not get caught on those permgen garbage collection woes!

There is also an option to require all strings to be interned (like Lua), and then strings hashing and comparing would be much, much faster. But this would either mean that we don't use Java's native string type (not good for compatibility), or use Java's string interning (again, permgen garbage collection woes!)

Oh, there is one last option, which I mentioned eariler, which would require creating anonymous classes/interfaces for each anonymous type, and then when casting between them, add a cast() layer that could take care of boxing the underlying type to the expected anonymous class/interface.
This option seems interesting, but we would really need to think of all the pros and cons of this approach. maybe after its first release ; )
I've decided to refactor the whole code (which was really needed, since it was my first ocaml project, and I wanted to use a strategy pattern to be able to easily setup modules of features for the targets, so in the end it was just a chaotic mess...), so by now I'm working to have it nice and usable for the haXe meeting on May! Will you come there? I'll talk about the implementations with more details + some benchmarks (and hopefully some comparisons with other languages like scala ) ;)

Cheers!
Cauê

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Cauê W.
In reply to this post by Justin Donaldson-3
2011/4/2, Justin Donaldson <[hidden email]>:
> This all sounds fantastic.  I thought for sure reflection would be a huge
> obstacle, congrats if you have it licked.  I'd really love to hear a trip
> report of the process, as well as hearing about any warts or problems that
> might require workarounds.

Well, I pretty much owe it to Hugh ! I just got inspired by the way he
made it work on the C++ target! : )

I just had to be careful to support native java code, so Reflect.field
will first test to see if the instance was generated by HaXe or not.
Also Java's Class<T> isn't mapped into HaXe's Class<T>, since we need
a reflection-enabled version of it. This got a little tricky since you
might want to convert a Java Class<T> (C#'s System.Type) into haXe's,
but for now I've solved this by using a Hash that gets lazily added.
It's not the best way to handle this,and might have some problems on
more complex application domain logics, but since I've never done
anything too complicated in that scenario, I don't have a better
solution yet!

>
> -Justin
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Cauê W.
In reply to this post by Tarwin Stroh-Spijer
2011/4/2, Tarwin Stroh-Spijer <[hidden email]>:
> Stupid question, but have you been keeping up with the stuff that Joa Ebert
> has been doing with JITB (
> http://blog.joa-ebert.com/2010/08/19/introducing-jitb/). Really interesting
> SWF > Java converter, with a great NME-like Java layer. Really worth
> checking out, and hopefully we don't have to duplicate our efforts when
> we're looking for NME-like layer - he showed it at Geeky by Nature and it's
> great.

Yeah! I've read about it. It's been some time he doesn't post about
it, hasn't it?
It seems he gone through many of the problems I've gone through by
making a target from a heavily reflection-enabled language to Java.
And it's really amazing work his JITB. I think it'll be very
straight-forward to make the externs for it!

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Gamehaxe
In reply to this post by Tarwin Stroh-Spijer
Hi,
I am also pretty sure I can get NME to run on java target with a
thin compatibility layer - it was pretty easy to get it going with
the v8 scripting.

Hugh

> Stupid question, but have you been keeping up with the stuff that Joa  
> Ebert
> has been doing with JITB (
> http://blog.joa-ebert.com/2010/08/19/introducing-jitb/). Really  
> interesting
> SWF > Java converter, with a great NME-like Java layer. Really worth
> checking out, and hopefully we don't have to duplicate our efforts when
> we're looking for NME-like layer - he showed it at Geeky by Nature and  
> it's
> great.
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321
> _______________________
>
>
> On Sun, Apr 3, 2011 at 12:24 PM, Cauê Waneck <[hidden email]> wrote:
>
>> Hey! : )
>>
>> 2011/4/2 Jordo Odroj <[hidden email]>
>>
>>> How are you going about implementing typedefs? Are you turning each of
>>> them into interface (in which case I can imagine my programs will be
>>> quite fast as you have said).
>>>
>>
>> So... I've thought a LOT about that, but I haven't come up with a good
>> solution. We -could- think of a way to implement anonymous types as a  
>> kind
>> of tuple, but the problem would be that you can't guarantee, but in very
>> special cases, that the anonymous type was actually generated with that  
>> kind
>> of tuple in mind. If HaXe had real tuples, that don't depend on the  
>> property
>> name, but their declaration order, this could be easily implemented.
>>
>> Some more complex solutions could be made, something in the line of what
>> javascript v8 does with its "inferred classes" (or something like  
>> that), but
>> I think I will leave this one for the future ; )
>> Anyway, what I've done so far is that I've tried to make reflection to  
>> be
>> as fast as possible, so using it isn't a problem. I've done this by
>> 1 - creating specialized containers for basic types, so they don't need  
>> to
>> be boxed
>> 2 - having a fast data-structure for acessing dynamic types (Basically  
>> I'm
>> performing a binary search in an array)
>> 3 - having the fastest way to compare strings - since our reflection is
>> string-based, we need to have a good way to compare them and still have  
>> good
>> performance. I chose (and that's what I said that isn't still  
>> implemented on
>> the java target) to implement a <= 30 chars string as 3 int64's. This is
>> done by restricting the possible chars of the string to what's legal in
>> haXe. And this is far the fastest way to compare strings (a full 30-char
>> string comparison actually takes 3 comparisons!). Of course, there is a
>> fallback for > 30 chars names using actual strings.
>>
>> The cool part about 3 is that the compiler will convert  
>> "myDynamicField" in
>> "myDynamicVar.myDynamicField" into the correct 3 int64's representation  
>> at
>> compile time, which means that it will be extra fast for when you don't
>> resort on Reflect.field .
>>
>> Those 3 optimizations are what I could think of to achieve the best
>> performance as possible for the target. Of course, what you said about
>> dynamic interfaces would be great, but they would either depend on a  
>> heavy
>> static analysis of what is being compiled (which would surely break when
>> dynamically loading modules). There is also the option to dynamically
>> generate java bytecode, but I'm avoiding that at all costs so the  
>> target can
>> be compatible, predictable and not get caught on those permgen garbage
>> collection woes!
>>
>> There is also an option to require all strings to be interned (like  
>> Lua),
>> and then strings hashing and comparing would be much, much faster. But  
>> this
>> would either mean that we don't use Java's native string type (not good  
>> for
>> compatibility), or use Java's string interning (again, permgen garbage
>> collection woes!)
>>
>> Oh, there is one last option, which I mentioned eariler, which would
>> require creating anonymous classes/interfaces for each anonymous type,  
>> and
>> then when casting between them, add a cast() layer that could take care  
>> of
>> boxing the underlying type to the expected anonymous class/interface.
>> This option seems interesting, but we would really need to think of all  
>> the
>> pros and cons of this approach. maybe after its first release ; )
>> I've decided to refactor the whole code (which was really needed, since  
>> it
>> was my first ocaml project, and I wanted to use a strategy pattern to be
>> able to easily setup modules of features for the targets, so in the end  
>> it
>> was just a chaotic mess...), so by now I'm working to have it nice and
>> usable for the haXe meeting on May! Will you come there? I'll talk  
>> about the
>> implementations with more details + some benchmarks (and hopefully some
>> comparisons with other languages like scala ) ;)
>>
>> Cheers!
>> Cauê
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Gamehaxe
In reply to this post by Jordo Odroj
Hi,
This code will actually perform pretty badly on c++, because
it must look up the variable by name.
The only ways around this would be an "adapter" class, or a template
function.  To some extent "easy to write" and "fast to run" are opposing
goals (although that's what compilers are for, right?)
However, you need to think about what is performance critical.
You will probably find you can use an "inefficient" form 95% of the
time, and only need to tweak 1 or two classes.

Hugh

> I just thought of a question: When you said "fully typed", I'm became
> concerned about how the code that I (personally) tend to write would
> perform. I tend to not use a lot of classes and interfaces, and
> instead use many typeDefs and rely on the structural subtyping system
> of haxe.
> How are you going about implementing typedefs? Are you turning each of
> them into interface (in which case I can imagine my programs will be
> quite fast as you have said).
>
> For example, in:
> typedef JordoType = {x:Int, y:String };
> ->I could imagine you make a java interface for this.
>
> Then when I instantiate an object of type JordoType:
> var someThing : JordoType = {x:3423, y:"cant wait for the java target!"};
> -> I could imagine you make a java "anonymous class"
>
> Is this how you are going about it (with Java anonymous classes)?
> If so, it seems that, yes, we can get insane speed by relying on Java
> paradigms that very naturally fit the Haxe type system. :)
>
> But then what do we do about structural type inference?
> Suppose that you have a function that accepts a JordoType
> pub fun myFunction(jt: JordoType) {
>
> }
>
> At some other point in the code: I might have:
> typedef CaueType = {x:Int, y:String, z:Bool};
> var someOtherThing : CaueType = {x:44532, y:"Heylo!", z:true};
>
> In haxe, I can pass the someOtherThing to myFunction() because the
> structural type system infers that CaueType is a subtype of JordoType.
> But if we implemented "someOtherThing : CaueType = ..." using java
> anonymous Classes, then how can we also ensure that I can pass an
> instance of CaueType to myFunc(jt: JordoType)?
>
> It seems like, for each new type declaration, we could find *all*
> possible declared types (or inferred) and ensure that every instance
> is properly is annotated as an anonymous Class of all the interfaces
> it matches as a subtype. That way, we could not have to resort to
> using reflection (and other slow means).
>
> (Please humor me, as I have no idea about how to implement a target,
> but I'm trying to learn what is involved in the process so that I can
> eventually contribute (to the java target, ideally).
>
> Jordo
>
> On Sat, Apr 2, 2011 at 2:42 PM, Cauê Waneck <[hidden email]> wrote:
>> Hey Jordo!
>> Well, tbh most of the optimizations I've only applied to c# by now,  
>> since
>> I've started to refactor the code. But most of them do also apply to  
>> java.
>> It's also harder to come up with a good microbenchmark on Java since it
>> really does well in optimizing virtual calls, so sometimes you think  
>> that
>> the performance is awesome, but it's just that the vm has inlined most  
>> of
>> your code and unwrapped a loop.
>> Well, anyway, what I can assure you is that:
>> - Fully typed haXe code will perform as if it was native java
>> - I am studying a concise haxe.rtti.Generic implementation for Java that
>> will allow haXe Arrays and Hash to perform better than ArrayList and
>> Hashtable equivalents, and make haXe array performance comparable to  
>> Java's
>> native array (fixed size)
>> - HaXe reflection (and anonymous types) is some orders of magnitude  
>> faster
>> than Java's builtin reflection. I've also made some optimizations on C#  
>> that
>> must also be applied to java (not done). This is not much considering  
>> the
>> poor Java/CLR reflection performance, but applying those new  
>> optimizations
>> should make it as fast as possible compared to fully typed code
>> - closures will perform almost as fast as virtual functions.
>> Cheers!
>> 2011/4/2 Jordo Odroj <[hidden email]>
>>>
>>> Caue,
>>>
>>> In your initial findings, what have you found the performance
>>> characteristics to be?
>>> I'm really excited about the Java target.
>>>
>>> Jordo
>>>
>>> On Wed, Mar 30, 2011 at 3:31 AM, Cauê Waneck <[hidden email]> wrote:
>>> > I think he's talking about the java haXe target.
>>> > If that's the case, I'm sorry but it's still not available. I intend  
>>> to
>>> > release it as soon as it's available for beta testing.
>>> > If you want to hear more about the new targets, you could show up at  
>>> the
>>> > haXe meeting on May! : )
>>> > By the way, don't worry the targets will have the same license as  
>>> HaXe
>>> > itself. But it's still not available right now.
>>> > I hope you understand,
>>> > Caue
>>> > 2011/3/30 Baluta Cristian <[hidden email]>
>>> >>
>>> >> why generate ocaml if java is much more similar?
>>> >>
>>> >> On Wed, Mar 30, 2011 at 1:23 AM, Raoul Duke <[hidden email]>  
>>> wrote:
>>> >>>
>>> >>> since ocaml can compile to the jvm, maybe just have haxe spit out
>>> >>> ocaml ha ha oy veh.
>>> >>>
>>> >>> On Tue, Mar 29, 2011 at 3:19 PM, Tyler MacLeod
>>> >>> <[hidden email]>
>>> >>> wrote:
>>> >>> > Hi all,
>>> >>> > I was wondering if the current effort to compile to a Java  
>>> target is
>>> >>> > available in a public repo somewhere. I don't really know OCaml,  
>>> but
>>> >>> > I'd
>>> >>> > like to see the progress.
>>> >>> > Thank you,
>>> >>> > Tyler
>>> >>> > --
>>> >>> > haXe - an open source web programming language
>>> >>> > http://haxe.org
>>> >>> >
>>> >>>
>>> >>> --
>>> >>> haXe - an open source web programming language
>>> >>> http://haxe.org
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Băluță Cristian
>>> >> http://ralcr.com
>>> >> http://imagin.ro
>>> >>
>>> >> --
>>> >> haXe - an open source web programming language
>>> >> http://haxe.org
>>> >
>>> >
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>> >
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Cauê W.
In reply to this post by Gamehaxe
2011/4/3, Hugh Sanderson <[hidden email]>:
> Hi,
> I am also pretty sure I can get NME to run on java target with a
> thin compatibility layer - it was pretty easy to get it going with
> the v8 scripting.

That's fantastic !

I was thinking also about a way to maybe auto-generate stubs so
C++/Java/C#/Neko can interface with native code. Maybe writing a
simple C .h parser and add some rules on top of it would do? Something
in the line of SWIG (but without the painful manual translation) ?
Maybe that could be made to work also with objective c's header files?

Also since we are using a compatible way to use reflection, maybe we
could also think of a way to directly integrate e.g. C++ code in neko
or C#? I don't really know the real possibility of this.

Cheers!
Cauê

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Nicolas Cannasse
In reply to this post by Gamehaxe
Le 03/04/2011 13:31, Hugh Sanderson a écrit :
> Hi,
> This code will actually perform pretty badly on c++, because
> it must look up the variable by name.

You could maybe using NekoVM hashing that is used for object
representation :

http://code.google.com/p/nekovm/source/browse/trunk/vm/others.c#357

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Cauê W.
Hi Nicolas! 

You could maybe using NekoVM hashing that is used for object representation :

http://code.google.com/p/nekovm/source/browse/trunk/vm/others.c#357


I saw that when I was looking at the neko sources to see how reflection is implemented there. But what isn't clear to me is that if this hashing is cached somehow, or a lookup into the tableis needed for each field access?

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Is the effort available?

Gamehaxe
In reply to this post by Cauê W.
Hi,
I think simple calls are ok, but things get a bit tricky when
references must be maintained - eg, haxe callbacks and context objects.
But something could certainly be done - maybe steal code from other
similar projects.  I have not thought too deeply about this.

I have also been thinking about neko/c++ compatibility and
v8/c++ compatibility and caching hxcpp compiles into libraries.
I think the new macro system may be what I need to get this going.
The idea is to compile hxcpp packages into ".lib/.a" files. eg, compile
the nme hx files and the hxcpp files once and store the result locally.
Then you can simply link against these.  The next step would be to
adapt one of the scripting languages to share the hxcpp GC and
then use scripting for parts of the code and pre-compile for other bits.
This would allow you to compile fast code (eg, use a pre-compiled physics
library) without needing to mess with a c++ compiler personally.
I think neko would be a very good match here.

I don't think it would be toooo hard, just need to find some time.

Hugh


> 2011/4/3, Hugh Sanderson <[hidden email]>:
>> Hi,
>> I am also pretty sure I can get NME to run on java target with a
>> thin compatibility layer - it was pretty easy to get it going with
>> the v8 scripting.
>
> That's fantastic !
>
> I was thinking also about a way to maybe auto-generate stubs so
> C++/Java/C#/Neko can interface with native code. Maybe writing a
> simple C .h parser and add some rules on top of it would do? Something
> in the line of SWIG (but without the painful manual translation) ?
> Maybe that could be made to work also with objective c's header files?
>
> Also since we are using a compatible way to use reflection, maybe we
> could also think of a way to directly integrate e.g. C++ code in neko
> or C#? I don't really know the real possibility of this.
>
> Cheers!
> Cauê
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
12