Sony's PlayStation Suite for Vita/Android Chooses C#/Mono Exclusively. What's the Alternative?

[clay]

A few months ago, Sony announced an upcoming hobbyist game development
platform that targets three hardware platforms: PlayStation 3,
PlayStation Vita, and certain Android devices.

Obviously, Sony and Microsoft own the two big video game platforms in
the video game space. Obviously, the Microsoft end of things is based
on an all Microsoft toolset. I'm very disappointed to see Sony also
promote an all Microsoft and Microsoft only development ecosystem. I'm
also disappointed that no other alternative was able to win over Sony,
given that Sony and Microsoft are complete arch rivals in that space.

Especially, after Google got so heavily sued for using Java in
Android, I presume Java and the JVM itself are off limits due to legal
issues.

However, isn't there an alternative? The JVM community has such a
vibrant selection of alternate programming languages that aren't bound
by Oracle's legal restrictions and are also better than Java/C#/C++
from a language perspective. There are also alternate runtimes, such
as LLVM, that aren't legally encumbered. I know Scala and Fantom have
some LLVM support (I don't know how stable/usable they are) and the
upcoming Kotlin has planned this as well.

What would be a game good development platform language/runtime
combination that could beat both C/C++ and C#/Mono and support high
performance, low overhead console-type games?

I'd like to hear this group's thoughts.

[Fabrizio Giudici]

On Mon, 16 Jan 2012 22:46:21 +0100, clay <clayt...@gmail.com> wrote:

> Especially, after Google got so heavily sued for using Java in
> Android, I presume Java and the JVM itself are off limits due to legal
> issues.

So, to avoid legal issues, Sony decided to put their balls into
Microsoft's hands? Brilliant!

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Josh Berry]

On Mon, Jan 16, 2012 at 5:00 PM, Fabrizio Giudici
<Fabrizio...@tidalwave.it> wrote:
> So, to avoid legal issues, Sony decided to put their balls into Microsoft's
> hands? Brilliant!

Probably more to ride on the popularity of XNA.

And I could be wrong, but I think the JVM takes a beating on most of
these platforms for lack of easy access to such items as unsigned
primitives and stack allocations. Waiting on a JIT is not an option
for most game developers.

[Fabrizio Giudici]

So, is the main reason the fact that C# also does AOT?

[clay]

C still outperforms both the JVM/CLI class of runtimes when it comes
to extremely performance sensitive applications and tight memory
constraints.

I really don't believe there is a performance problem with Java/JVM vs
Mono.

When you cite Mono as having big performance advantages and cite the
stack allocation feature: Have you experienced this or read any type
of credible study that shows this? Because this sounds like FUD. I've
heard people make the same claim and cite benchmarks from Miguel de
Icaza's blog where they show that Mono allocates 1000 stack allocated
structs faster than Java/Dalvik allocates 1000 classes on the heap and
these were touted around the web. There is a grain of truth to the
benefits of stack allocation, but it's such a convoluted unrealistic
case and the guys were obviously trying to make Java/Dalvik runtime
look bad.

I've done *LOTS* of C# high performance code myself (never Mono,
always the Microsoft .NET version) and I've done many benchmarks
myself and I've seen Java often does better. I don't want to get into
a C#/Mono vs Java debate, those degenerate into garbage way too
quickly.

But I do want to hear people's ideas for a dream hobbyist game
development environment that provides an alternative to the Microsoft
ones.

On Jan 16, 4:50 pm, Josh Berry <tae...@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 5:00 PM, Fabrizio Giudici
>

[Josh Berry]

I'm not sure I understand the AOT angle. Sorry.

On Mon, Jan 16, 2012 at 8:17 PM, clay <clayt...@gmail.com> wrote:
> C still outperforms both the JVM/CLI class of runtimes when it comes
> to extremely performance sensitive applications and tight memory
> constraints.
>
> I really don't believe there is a performance problem with Java/JVM vs
> Mono.
>
> When you cite Mono as having big performance advantages and cite the
> stack allocation feature:

Apologies, I wasn't trying to say for sure that Mono has a definite
performance advantage. So, first let me reiterate what I think was
the main draw, the large base of developers already doing game
development in C# with the XNA tools.

That said, I just saw the hacker news floating of the old jgit versus
cgit email* recently and it reminded me of some of the crazy crap that
game developers do. In particular, tricks such as "doing a copy from
an inflated tree into a struct object." Now, I could be wrong, but I
thought in C# it was possible to do tricks such as this with an
"unsafe" region. (In case it isn't clear, I'm not an experienced C#
programmer. So, if I'm wrong, let me know. :) )

*http://news.ycombinator.com/item?id=3455673

[clay]

I read the JGit email: he's right. unsigned types are definitely a
plus and a JVM deficiency but it's usually not a huge performance deal
by itself in the context of a full application. You have a good point
about "unsafe" in C#, but you can also use JNI to integrate Java with
high performance optimized C. But bottom line, performance is
typically never a deciding factor between JVM and CLI/Mono.

Your main point is spot on: it's a brand issue. Microsoft's game
playing and game development brands like Xbox/XNA/XBLA/DirectX/C# are
very popular. Anything related to Java is not. And most people view
terms like "Scala" or "Haskell" as just foreign jibberish. With this
type of crowd, most people have zero or very limited development
experience, and it's more perception and brand preference than deep
technical issues.

But even for the Microsoft fans: the Sony PlayStation Suite doesn't
give them the full XNA and XBLA tool chain. Microsoft's Xbox and
Sony's PlayStation platforms are similar but intensely competitive
rivals, and the fans are strongly divided as well. Much of the
Microsoft fanbase will choose to develop for Xbox Live and/or Windows
Mobile rather than a PlayStation/Android SDK. If there's anywhere for
a viable tool chain alternative to MIcrosoft, this is it.

[Josh Berry]

On Tue, Jan 17, 2012 at 1:36 PM, clay <clayt...@gmail.com> wrote:
> I read the JGit email: he's right. unsigned types are definitely a
> plus and a JVM deficiency but it's usually not a huge performance deal
> by itself in the context of a full application. You have a good point
> about "unsafe" in C#, but you can also use JNI to integrate Java with
> high performance optimized C. But bottom line, performance is
> typically never a deciding factor between JVM and CLI/Mono.

I could be wrong, but JNI doesn't really act as a good "unsafe"
replacement. I tried searching quickly, but couldn't find any good
links. Essentially, I'm lead to believe that JNI calls can actually
be rather expensive. And, especially with some of the insane tricks
I've seen to quickly take a byte of data from a network packet and
turn it into a struct (yeah yeah, I know this is old hat for c
coding...), I think these add up heavily in common code for game
development.

> playing and game development brands like Xbox/XNA/XBLA/DirectX/C# are
> very popular. Anything related to Java is not. And most people view
> terms like "Scala" or "Haskell" as just foreign jibberish. With this
> type of crowd, most people have zero or very limited development
> experience, and it's more perception and brand preference than deep
> technical issues.
>
> But even for the Microsoft fans: the Sony PlayStation Suite doesn't
> give them the full XNA and XBLA tool chain. Microsoft's Xbox and
> Sony's PlayStation platforms are similar but intensely competitive
> rivals, and the fans are strongly divided as well. Much of the
> Microsoft fanbase will choose to develop for Xbox Live and/or Windows
> Mobile rather than a PlayStation/Android SDK. If there's anywhere for
> a viable tool chain alternative to MIcrosoft, this is it.

I think you are dismissing the amount of example code out there in C#
for doing game development.

So, lets turn this around. Why would you have picked a different
platform? Why do you feel that the stuff Microsoft has created is a
bad choice?

[clay]

"So, lets turn this around. Why would you have picked a different
platform? Why do you feel that the stuff Microsoft has created is a
bad choice?"

I'm not trying to convince others that they are making a bad choice or
evangelize my views. But personally, I feel that the JVM ecosystem
operates more as a meritocracy while the .NET/Mono landscapes function
more as monarchies.

In the .NET/Mono landscapes, when you are choosing an IDE, a database,
a web framework, a build system, or whatever: the prevailing attitude
is that every developer should use the dominant Microsoft technology,
Microsoft Best Practices are the ultimate gospel, and using any
alternative to any Microsoft product risks you being branded as a
Microsoft hater which is the ultimate heresy. There are lots of
exceptions; there are alternate .NET web frameworks, build systems,
and Mono itself is a completely alternate runtime. But the community
acceptance of alternatives is generally very low. And the driving
spirit behind Mono isn't to pioneer some new technology or deliver
improved variations of the standard Microsoft options, it's to crusade
the Microsoft gospel to foreign territory. Lots of people love this
stuff and are fueled by Microsoft spirit and pride, but I find this
ecosystem stifling and repressive.

In the JVM landscape, technologies live or die more on their own
merit. The community cares little about Sun/Oracle endorsement. JSF
was the official web framework from Sun, but it was horrible, and
almost everyone used independently developed alternatives. Several
generations of build systems (Ant, then Maven, and now Gradle or SBT
are fighting for the next gen) have risen and fallen in the Java
landscape and all of them (AFAIK) were developed by independent
developers and they took off not because of a corporate endorsement,
but rather because they were just really, really good, and word
spread. You can see the same thing with an amazing selection of IDEs
and now there is also an amazing selection of competing alt-languages
(Fantom, Scala, Clojure, Groovy, Kotlin, etc).

"I could be wrong, but JNI doesn't really act as a good unsafe
replacement."

I suspect that you may be right that Java doesn't have as good an FFI
story as C# or Lua. But it's used in things like JOGL, which is
extremely nice, since you can have a Java game where all the low level
OpenGL rendering happens with the native OpenGL libraries.

Just googling, I found what looks like a pretty meticulous and up to
date programming language benchmark site: http://shootout.alioth.debian.org.
C++/G++ is faster than Java which is faster than C#/Mono. And the gap
between Java and Mono is larger than the gap between Java and C++.
It's a Debian site so they don't have data for Microsoft's .NET
runtime which is Windows-only.

If I google "java C# benchmarks", the top link (http://
reverseblade.blogspot.com/2009/02/c-versus-c-versus-java-
performance.html) posts results from another site called
http://www.csharp-architect.com. The results show from faster to
slower: C++, C#/Microsoft, Java, C#/Mono.

I understand having true unsigned integer primitives give you a small
boost when heavy unsigned integer math, like in the Git example where
they do high volume SHA-1 hashing. I also see the benefit of C#'s
unsafe mode. I also like several other C# features that Java doesn't
have. But, in most benchmarks, I see Java running *faster* than Mono,
even on a site called csharp-architect.com. And in the hundreds of
conversations I've had with C# developers, I've heard a lot of
criticisms of Java, but runtime performance is generally not one of
them.

Even Microsoft's internal game studios do their game engines in C/C++
rather than C# and use various higher level languages (Lua, etc) for
higher level game event scripting type of work. Microsoft has
presented C# as an easier option that lowers the barrier to
development entry, but not (yet) as the development platform for
premier games.

PlayStation uses C/C++ for their real dev kits for performance
reasons. For their hobbyist SDK, they are willing to take a
performance hit in exchange for improved accessibility.

Bottom line: there is no evidence that performance is a problem with
Java for this type of hobbyist SDK. If anything Java runs
significantly faster than Mono/C#.

[Vince O'Sullivan]

On Jan 18, 6:57 am, clay <claytonw...@gmail.com> wrote:
> Bottom line: there is no evidence that performance is a problem with
> Java for this type of hobbyist SDK. If anything Java runs
> significantly faster than Mono/C#.

Another bottom line for Sony et al is that the number of good games
written in Java can be counted on the fingers of one hand, and a
rather badly mutilated hand at that.

[ushac]

I haven't tried C# unsafe, but it definitely looks better than JNI. In
fact, Oracle has openly admitted that JNI was intentionally designed
to be hard to use in order to push people to write pure Java.

JNI isn't only hard to use, it can be pretty slow as well. The
function calls themselves aren't that bad, but stick to primitive
parameters/return values and direct ByteBuffers for any data the needs
to be passed between native and Java. Setting a field in a java object
from native costs (on my machine) something like 50ns, which on its
own isn't much, but still about 100x more than doing it in pure Java.
So don't do that on a critical path!

At JavaOne 2011 Oracle casually mentioned that they hope to improve
native handling in Java 9. I hope they do, and wouldn't be surprised
if it looked a lot like "unsafe".

Regards,
Erik Språng


On Jan 17, 8:00 pm, Josh Berry <tae...@gmail.com> wrote:

[Ricky Clarkson]

Where can I read that admission by Oracle?

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Casper Bang]

I'm very disappointed to see Sony also
promote an all Microsoft and Microsoft only development ecosystem.

I reckon it comes down to two things: 1) Sony is notoriously proprietary and 2) Pareto principle. They can get to 80% of developers with 20% the cost. Go ahead and ask Google how easy it is to cater to multiple platforms. After several years, they still receive massive criticism for the performance of the device simulator. And remember, unlike Java, the C# language itself is an approved standard under ECMA/ISO, so you are not required to use Microsoft's proprietary implementation. That's why you can currently develop for iOS and Android devices, even if Microsoft makes no SDK available for these platforms (Xamarin does however).

 

Obviously, Sony and Microsoft own the two big video game platforms in 
the video game space. Obviously, the Microsoft end of things is based 
on an all Microsoft toolset. I'm very disappointed to see Sony also 
promote an all Microsoft and Microsoft only development ecosystem. I'm 
also disappointed that no other alternative was able to win over Sony, 
given that Sony and Microsoft are complete arch rivals in that space. 

If you want a modern, static language catering to high performance, then C# really is hard to beat. It has the best parts from Java but improves on it across the board. When it comes to game development, being able to work on unsigned types, use pointers, call native code, use stack based value types (structs), use out parameters (i.e. implement swap), compile AOT (fast launch), use SIMD instructions etc. is a big advantage. Those are some of the things I remember the Unity (Mono) developers talking about [http://unity3d.com/unity/].

What would be a game good development platform language/runtime 
combination that could beat both C/C++ and C#/Mono and support high 
performance, low overhead console-type games? 

Perhaps some of the new languages like Go, but they will definitely need to embrace concurrency and interoperability, rather than try to define and demarcate the world as Java did by mandating a widget library, making JNI so bloody terrible etc.

[ushac]

They said it at the JavaOne strategy keynote, but I believe I heard it
before. Can't recall where though.

E

[Casper Bang]

On Wednesday, January 18, 2012 12:56:52 PM UTC+1, ushac wrote:

They said it at the JavaOne strategy keynote, but I believe I heard it
before. Can't recall where though.

You have probably heard it from, then J++ chief architect, now C# chief architect, Anders Hejlsberg, when he was interviewed back in the day by Bill Venners and Bruce Eckel: http://www.artima.com/intv/anders.html

It is not usually Sun/Oracle's policy to admit mistakes. Case of point, their infamous paper on delegates:

http://java.sun.com/docs/white/delegates.html

[ushac]

http://medianetwork.oracle.com/video/player/1176404813001

About 21min in.

On Jan 18, 1:16 pm, Casper Bang <casper.b...@gmail.com> wrote:
> On Wednesday, January 18, 2012 12:56:52 PM UTC+1, ushac wrote:
>
> > They said it at the JavaOne strategy keynote, but I believe I heard it
> > before. Can't recall where though.
>
> You have probably heard it from, then J++ chief architect, now C# chief
> architect, Anders Hejlsberg, when he was interviewed back in the day by
> Bill Venners and Bruce Eckel:http://www.artima.com/intv/anders.html

Nope, that's not it. :)

[clay]

On Jan 18, 5:09 am, Casper Bang <casper.b...@gmail.com> wrote:

> If you want a modern, static language catering to high performance, then C#
> really is hard to beat. It has the best parts from Java but improves on it
> across the board. When it comes to game development, being able to work on
> unsigned types, use pointers, call native code, use stack based value types
> (structs), use out parameters (i.e. implement swap), compile AOT (fast
> launch), use SIMD instructions etc. is a big advantage. Those are some of
> the things I remember the Unity (Mono) developers talking about [http://unity3d.com/unity/].

I just posted links to benchmarks showing Java consistently
outperforming C#/Mono by a wide margin across a whole suite of
different benchmark tests. Instead of responding to these, you just
repeat the standard C# talking points which we *just* talked about at
length.

Ideally, the JVM would be better and faster at scooping up some of the
features from the CLR runtime. It would probably break too much legacy
code to introduce unsigned integer types to Java, the language, but
there is no reason it can't be added at the VM level where it can be
optionally adopted by the alt language community.

"That's why you can currently develop for iOS and Android devices,
even if Microsoft makes no SDK available for these platforms (Xamarin
does however)."

The Mono team did an awesome job providing tool chains that included
embedded CLR runtimes for devices like iOS/Android that don't have
system level CLR runtimes. The same style of tool chains allow them to
make apps for Google Chrome Native Client (NaCL) and now PlayStation
Vita.

I'd like to see the JVM community build something like this. I'd like
to be able to use my favorite JVM languages/libraries/IDEs and make
executables with an embedded JVM that can run by itself on Windows, or
run in Google Chrome NaCL or potentially run on the Vita.

You are saying that the licensing differences between CLR and the JVM
prevent this from happening. Can you show me evidence of this? The
Mono team could have done exactly the same thing with the JVM.
Unfortunately, they didn't and no one else has, but I don't see any
legal or technical barriers to this.

"It [C#] has the best parts from Java but improves on it across the
board"

Generally, yes, C# the language is an incremental improvement upon
Java the language. And the reason people choose Java is when the
flexibility and community benefits outweigh the minor language level
incremental improvements of C#. However, even Java the language has
some better points. For example, Java has a richer set of enums with
more type safety and more functionality. That's a small feature, but I
use enums heavily in code that I write. A second point, is more
features isn't always better. They give you more rope to hang yourself
with. You can really see this with Scala; sometimes I look at some
Scala code written by some Scala enthusiasts and it uses so many
syntax features in such obscure ways, that it is impossible for mere
mortals to understand.

Secondly, the F#/Scala/Clojure languages aim to provide more than an
incremental improvement on Java, they are aiming for a full paradigm
shift.

But, even if you don't want that full paradigm shift, and want a
safer, incrementally improved OO language, the forthcoming language
Kotlin looks to one up both C# and Java.

Actually, if I were to name one of the bigger technical advantages of
JVM over .NET: build tools. The .NET world is in the dark ages. They
still use IDE auto-generated auto-maintained .csproj/msbuild files. In
the Java world, even the old Ant was better than this. Then Maven came
a long as a much better system and became the standard in the Java
community. Now, we see Gradle or SBT emerging as the new bleeding
edge. Rather than have a kludgy build script that requires tools to
auto-edit to be usable, the Java world has build languages that are
elegant enough to be maintined by hand, and developers can optionally
add an IDE type tool on top of that.

And while JVM's build tools put .NET in the dark ages, C/C++ and
Haskell are even worse. They are still using makefiles where you have
to encode logic to check the file date on your .o files and compile
the .c (or .hs) files and name all your .o files to link them
together...

"In fact, Oracle has openly admitted that JNI was intentionally
designed to be hard to use in order to push people to write pure
Java."

C/C++ allowed programmers to write unsafe code. And despite endless
style guides and code reviews this frequently led to problems. Java
completely stopped programmers from doing crazy pointer manipulation
and gives you an absolute compiler level guarantee of protection from
a whole class of problems that were rampant in the C/C++ world. At the
same time, there are some cases, were you have to sacrifice runtime
performance. C# made a different compromise and took a different trade
off.

Also, I've never used JNI directly, but I've used JOGL and JavaCL
which use JNI internally and shield you from the details.

[Cédric Beust ♔]

On Wed, Jan 18, 2012 at 1:50 AM, ushac <ush...@gmail.com> wrote:

I haven't tried C# unsafe, but it definitely looks better than JNI. In
fact, Oracle has openly admitted that JNI was intentionally designed
to be hard to use in order to push people to write pure Java.

Yeah, I don't buy that, it sounds a lot like post rationalization to me.

First, JNI is pretty straightforward to use and the API is pretty easy.

Second, JNI has been slow for a very long time (or to be more precise, what's slow is crossing the boundary between Java and C, and it's no longer as true today as it was then) but I very much doubt it was by design. I think Sun simply observed they couldn't make it fast and decided to claim that it was intentional, which went along with their message of trying to encourage people to use Java.

-- 

Cédric

[Ricky Clarkson]

I think you might be overestimating the difficulty of adding language features.

Also, of F#, Scala and Clojure, Scala *is* an incremental improvement. Its feature set panders just as much to the OO programmer as the functional.

If anything I'd like it to be more opinionated.

-----Original Message-----
From: clay <clayt...@gmail.com>
Sender: java...@googlegroups.com
Date: Wed, 18 Jan 2012 09:08:10
To: The Java Posse<java...@googlegroups.com>
Reply-To: java...@googlegroups.com
Subject: [The Java Posse] Re: Sony's PlayStation Suite for Vita/Android
Chooses C#/Mono Exclusively. What's the Alternative?

[clay]

On Jan 18, 12:08 pm, "Ricky Clarkson" <ricky.clark...@gmail.com>
wrote:

> I think you might be overestimating the difficulty of adding language features.
>
> Also, of F#, Scala and Clojure, Scala *is* an incremental improvement. Its feature set panders just as much to the OO programmer as the functional.
>
> If anything I'd like it to be more opinionated.

Scala absolutely caters to the traditional OO programmer and lets you
use it as a Java++. And I believe that is what the majority of Scala
programmers are doing. However, Scala supports more serious functional
style immutable programming beyond what you get with C# or Fantom or
Kotlin or Java 8 (with first class functions). Scala aims to
compromise between a Haskell like pure functional approach and give
you full JVM interop and compatability.

What do you mean I'm overestimating the difficulty of adding language
features?

Someone privately messaged me this link:
http://shootout.alioth.debian.org/demo/benchmark.php?test=all&lang=csc&lang2=java

That's the same suite of comprehensive benchmarks but compares Java 7
to C#/.NET (Microsoft's implementation as opposed to Mono) running on
Windows.

Java 7 comes out as quite a bit faster.

This coincides with my personal experience of benchmarking key pieces
of software that I'm working on and comparing Java 7 to C#/Microsoft
on my Windows laptop.

So Java 7 is faster than C#/Microsoft which is faster than C#/Mono. I
assume this is due to a more polished/tuned VM rather than a language
level feature difference.

I'd also say that unsigned integer support is still a good idea for
the JVM to adopt and maybe stack allocation as well, but these
features don't seem to be huge performance factors by themselves in
most cases.

[Josh Berry]

On Wed, Jan 18, 2012 at 3:39 PM, clay <clayt...@gmail.com> wrote:
> I'd also say that unsigned integer support is still a good idea for
> the JVM to adopt and maybe stack allocation as well, but these
> features don't seem to be huge performance factors by themselves in
> most cases.

One thing you need to be careful with on these benchmarks is memory
usage. Especially targeting the ps3, memory is not exactly free.
Same for throughput of data if you require anything off of the disc.
So, how long does it take to read a meg off the disk and process it as
program data?

In other words, these benchmarks are likely completely irrelevant.

Also, you keep looking at stack allocation and unsigned types. I
think the more important "unsafe" trick is the ability to memcpy into
a struct. The unsigned part is one thing, but actually being able to
say the next "5k bytes from the disc is an array of this struct" is
huge. Well.... I say that. It sounds huge. I could definitely be
wrong. :)

[Ricky Clarkson]

I think we agree on Scala.

Regarding language changes, you seemed to assume that adding unsigned to Java would break legacy code. I don't see why it should.

-----Original Message-----
From: clay <clayt...@gmail.com>
Sender: java...@googlegroups.com
Date: Wed, 18 Jan 2012 12:39:25
To: The Java Posse<java...@googlegroups.com>
Reply-To: java...@googlegroups.com
Subject: [The Java Posse] Re: Sony's PlayStation Suite for Vita/Android
Chooses C#/Mono Exclusively. What's the Alternative?

[clay]

I've wrote a Java app that loaded millions of records, ~2.5GB on disk,
into memory, and ready to be analyzed in about 3-4 seconds on my
laptop on a warm run. Cold runs took a little longer, I forget the
exact time, but it was in the 5-12 second range. The main trick was
storing my data by columns rather than by rows. Using the right NIO
API you can read massive arrays of primitives (int[], long[], float[])
directly from disk into memory without any Java loops. I imagine this
was completely bound by OS level I/O operations. Conceptually, I don't
see how you'd squeeze more performance out of this with C-style
casting and memory copies. My point is that sometimes you can find
high performance tricks even in Java to do the types of tasks you are
talking about.

Memory use is a big issue on consumer devices. The JVM may have
problems in this area; obviously server applications can generally
afford to spare much more RAM, and maybe the JVM has been heavily
tuned for that. But nevertheless, I don't think there are any
technical barriers that would stop the JVM from having a competitive
memory footprint.

It seems like there is a decided lack of enthusiasm about Java and the
JVM ecosystem. People are just searching for reasons why it isn't
good. Does anyone want to see it improve and broaden it's usefulness?

[Simon Ochsenreither]

Because there are hundred pieces of code in the wild that assume there are only 8 primitive types (or 9 Wrapper types).

But yes, at least unsigned integer math is coming in Java 8, afaik.

[Ricky Clarkson]

Can you give an example of such code that would cease to work should
Java add unsigned ints?

[Reinier Zwitserloot]

::facepalm::

The mind boggles at how idiotic sony's actions are of late. I'm perfectly willing to entertain the thought that legally speaking mono has better cards, at least superficially, than anything with the letter J in it anywhere, but, you don't put your eggs in the basket woven by your only direct competitor in your patch of the ocean, that's just beyond stupid.

Fortunately at least the Vita is DOA. Nintendo has a proven track record holding on to whatever passes for 'portable gamer', and the iPhone and android itself are bollocksing that market up anyhow. So that leaves a sony spin on android which is, I presume, similarly doomed to fail, so then there's just PS3 dev. I'm guessing hobbyists that do want to develop for this platform want to develop directly on the raw iron. Durdling a few things together with a what must be very crappy API if it can be cross-compiled to Vita, PS3, and Android can't be all that exciting, but, maybe I don't have my finger on the pulse of the hobbyists, always an option.

Colour me unphased for now.

[Josh Berry]

On Wed, Jan 18, 2012 at 5:05 PM, clay <clayt...@gmail.com> wrote:
> I've wrote a Java app that loaded millions of records, ~2.5GB on disk,
> into memory, and ready to be analyzed in about 3-4 seconds on my
> laptop on a warm run. Cold runs took a little longer, I forget the
> exact time, but it was in the 5-12 second range. The main trick was
> storing my data by columns rather than by rows. Using the right NIO
> API you can read massive arrays of primitives (int[], long[], float[])
> directly from disk into memory without any Java loops. I imagine this
> was completely bound by OS level I/O operations. Conceptually, I don't
> see how you'd squeeze more performance out of this with C-style
> casting and memory copies. My point is that sometimes you can find
> high performance tricks even in Java to do the types of tasks you are
> talking about.

I am willing to bet dollars to donuts that your laptop is a bit more
capable than the machines that are targeted here.

And, again, read what you wrote. You read massive arrays of
*primitives* into memory. Now... what if that primitive was an image
and you'd like to treat it as such? In java, you're hosed. It is
getting copied to the heap. In C#, it appears, you can avoid this
copy and just treat the data as what you know it is. Or, do you think
the answer to writing high performance sections of code is that
everything has to be a primitive throughout your app? (Remember, as
soon as you make it an object in java, it is copied to the heap.) Not
to mention in C# it is just a lot easier to interface with C/C++ code
directly.

> It seems like there is a decided lack of enthusiasm about Java and the
> JVM ecosystem. People are just searching for reasons why it isn't
> good. Does anyone want to see it improve and broaden it's usefulness?
>

I don't know what to tell you. Game developers by and large avoid
Java. I think if you honestly want a good answer as to why, ask them.
It seems rather clear that none of us are game developers. I've
given my overall opinions, but they can only go so far.

And, as much as I used to fear all things Microsoft, I still maintain
this was not a ploy to attract Microsoft developers. This was
acknowledging that toolsets such as Unity3D already exist and have a
C# API. Why not leverage the hobby groups that currently exist?

Also, it isn't like anyone here dismisses the JVM. We just can't
offer any compelling reason why game developers should choose it over
alternatives.

[clay]

On Jan 18, 9:09 pm, Josh Berry <tae...@gmail.com> wrote:
> I don't know what to tell you.  Game developers by and large avoid
> Java.  I think if you honestly want a good answer as to why, ask them.

Thanks Josh. I think I figured this out. And I think I can articulate
this better than most game developers could (I don't think game devs
have thought as much about this issue or the JVM as I have):

The most important missing feature is having easy to use, embeddable,
micro-VMs. Microsoft .NET doesn't have this, but the Mono guys made
their own implementation of the CLR with this as a primary concern.
There are no legal or technical obstacles stopping this from happening
on the JVM side, it's just no one has done it.

Game developers want to target iOS, Android, and PlayStations. Those
devices do not and will not run traditional system-level Java.
Embeddable micro-VMs are the solution and they don't exist yet on the
JVM side. I really wish I had gone to grad school for this type of
stuff, because I think this is a hot project but it requires a
specialized set of skills to do well.

The second issue is the programming language. Ideally, you support
multiple languages, but you still need a flagship language. Java, the
language, is behind the times. C#, the language, has incrementally
improved upon Java overall. However, there are other languages that
deliver even further incremental improvements. I don't think the game
development community is ready for the type theory, the deep
abstractions, and the radical nature of Haskell or Clojure. I think
the most promising candidate is the forthcoming Kotlin. It definitely
one ups Java/C# and doesn't require paradigm shifts and I'm hoping it
won't have the compilation speed penalty and runtime speed penalty
that Scala seems to have.

What else do we want from Java: the super IDEs and the build tools. As
I explained earlier, the Java build tools are really at the leading
edge of the industry. And almost every dev I know that has used it
would pick IntelliJ any day over Visual Studio.

But to resummarize an earlier point: I don't think runtime performance
is a problem with the JVM. Even without "unsafe" casting and memcpy
type tricks and the issues you raised, the JVM generally outperforms
both Microsoft's CLR and Mono. The two of you in this thread that
insist this is a problem are just not being reasonable.

> Also, it isn't like anyone here dismisses the JVM.  We just can't
> offer any compelling reason why game developers should choose it over
> alternatives.

I can articulate some compelling reasons:

- Kotlin is a better, more exciting, and more elegant language than
C#.
- Better IDEs and wider selection of IDEs.
- Better runtime performance.
- Better build tools and a wider choice (Maven, Gradle, SBT).
- A deeply meritocratic culture rather than one that is forever in
lock step behind a corporate despot.

"Can you give an example of such code that would cease to work should
Java add unsigned ints?"

I can't, but I haven't thought about this issue deeply. You may know
this issue better than I.

"But yes, at least unsigned integer math is coming in Java 8, afaik."

Where did you hear this? Do you have a link? I can't find this on
google.

FYI, I remember during this last year, famous game programming expert
John Carmack posted on his Twitter about some unsigned integer corner
case that caused problems and said something to the effect of maybe it
wasn't a bad thing for Java to avoid them. I am unable to dig up the
exact quote/link at the moment.

[Simon Ochsenreither]

Hi,

 

The most important missing feature is having easy to use, embeddable,
micro-VMs. Microsoft .NET doesn't have this, but the Mono guys made
their own implementation of the CLR with this as a primary concern.
There are no legal or technical obstacles stopping this from happening
on the JVM side, it's just no one has done it.

I guess the reason is that Microsoft hasn't sued anybody over their implementation.
The requirements, the wording and the experience around getting the TCK and being an "official Java" vs. having something like an "Android" status too scary for everybody.
Too much bureaucracy, too many worries about lawyer stuff.
 

What else do we want from Java: the super IDEs and the build tools. As
I explained earlier, the Java build tools are really at the leading
edge of the industry. And almost every dev I know that has used it
would pick IntelliJ any day over Visual Studio.

Calling Maven (and Ant) "leading edge of the industry", (which is what about 95% of the developers have to use) is not without irony.

The Java ecosystem is just a place where "the standard tool" is almost always preferred over "the best tool for the job".
With dogmatism replacing pragamtism over the last 10 years it is not surprising that many of the more progressive developers left Java-the-language or even Java-the-ecosystem.

Same thing with IDEs: It doesn't help to have superior tooling (IntelliJ or Gradle, SBT) when no one uses it.
With Eclipse being obviously optimized for rebranding by plugin providers instead of usability, Visual Studio the winner here.
 

"But yes, at least unsigned integer math is coming in Java 8, afaik."

Where did you hear this? Do you have a link? I can't find this on
google.

http://permalink.gmane.org/gmane.comp.java.openjdk.core-libs.devel/8937
http://cr.openjdk.java.net/~darcy/4504839.1/
 

I think the most promising candidate is the forthcoming Kotlin. It definitely
one ups Java/C# and doesn't require paradigm shifts and I'm hoping it
won't have the compilation speed penalty and runtime speed penalty
that Scala seems to have. 

[...]

 - Kotlin is a better, more exciting, and more elegant language than C#.

I wonder where all this wishful thinking comes from. It is not like we couldn't actually check stuff instead of repeating the claims from the marketing slides.
Kotlin, Ceylon, Gosu - everything is available in one form or another.


My notes from last week:

Kotlin:

• Very immature, but the browser applet/JavaScript thing is interesting.
  
• Winner in the category "compiler crashes" with 3 crashes in 20 minutes.
  
• Syntax-wise almost identical to Scala and getting closer.
• No mailing lists, not open source yet.
• As far as I have understood, it targeted to be "just a language", reusing the Java standard library.
  

Ceylon:

• Surprisingly bad compiler error messages.
• Nice website. Source available.
  
• Winner in the category "ignoring every piece of language design knowledge". Just read the mailing list. Very painful.
• Also winner in the category "let's change every keyword just for the sake of it".
  
• Plans to completely replace the Java ecosystem with own implementations.
• Obscure type system research and changes even after "two years of development", especially for a language trying to be "industrial".
  

 Gosu:

• Their "IDE" is very limited, primitive. Wondering why they feature their Eclipse/IntelliJ not more prominently. Probably even more limited than their own IDE...
• Winner in the category "Obsolete when Java 8 arrives", but:
• Interesting ideas (open type system), although I think F# type providers are a more consistent approach.
• The unfortunate compromises in language design give the language the hackish feeling of Groovy.
• Good documentation, but somehow I didn't find a link to the source code, also no nightles.
• Not much development going on at the moment.

All languages have two things in common:

• They are OO/functional in the C#/Scala way
• They promise reified Generics, but fail to deliver

Would be nice to get some other _constructive_ criticism instead about believing everything language creators say...

Bye,

Simon

[Cédric Beust ♔]

On Thu, Jan 19, 2012 at 12:46 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

Kotlin: 

 

Very immature, but the browser applet/JavaScript thing is interesting.

• Winner in the category "compiler crashes" with 3 crashes in 20 minutes.
  
• Syntax-wise almost identical to Scala and getting closer.
• No mailing lists, not open source yet.
• As far as I have understood, it targeted to be "just a language", reusing the Java standard library. 

You're aware that it's not even released, right? And I mean, not even in beta or alpha form. It's just not there at all.

As for Ceylon, it's an Alpha at best. How about giving these languages a couple of years before trying to judge them? After all, Java has a 17 year head start and Scala about eight.

Your constant negativity toward anything that might compete with Scala is quite puzzling. Be more open-minded.

> Would be nice to get some other _constructive_ criticism 

Indeed.

-- 

Cédric

[Simon Ochsenreither]

As for Ceylon, it's an Alpha at best. How about giving these languages a couple of years before trying to judge them? After all, Java has a 17 year head start and Scala about eight.

Funny how that argument works the other way around. But if someone mentions that those languages are years apart from production use, I know who is the first to cry "foul". :-)

I think there is nothing wrong with comparing languages (especially if they began with it). You can't really claim it is other people's fault that they are ten years late to the party.

Your constant negativity toward anything that might compete with Scala is quite puzzling. Be more open-minded.

 

I have tons of criticism about Scala, but with certain people being on a constant crusade against the language, I can spend my time on better things.

The thing is that I actually try stuff before commenting. You did that too, right?

[Fabrizio Giudici]

On Thu, 19 Jan 2012 04:09:06 +0100, Josh Berry <tae...@gmail.com> wrote:

> And, again, read what you wrote. You read massive arrays of
> *primitives* into memory. Now... what if that primitive was an image
> and you'd like to treat it as such? In java, you're hosed. It is
> getting copied to the heap.

Perhaps I didn't understand the point, but in Java you can used memory
mapped I/O and have it accessible outside of the heap.

Honestly I have also other questions. I only had a short experience with
gaming (from the programming point of view) between 1992-1995, across my
primary graduation, when I was writing for fun a flight simulator. It was
DOS time, accessing memory beyond 640K was already a problem and I started
with a drawLine() getting up to the (gamish) simulation of a US
supercarrier getting attacked by a USSR Tupolef Bear. I did all the
primitives by myself, also trying alternate ways than the state of the
art, and I had things that other games of the time didn't have, such as
full 3D cockpits and Doppler effect on digital audio (of course, the
application had never been polished enough for being commercialized, since
it was just fun). So, I have an idea of what pulling the CPU power from
any bit means. But is it today still the same thing? I understand that
games are much more complex, but we have specialized hardware for graphics
and sound... Are really technical the reasons for preferring C# to Java?
Or maybe the reason game developers prefer C# is simply the fact that
Microsoft has created since many years a gaming business segment, and Sun
just didn't?

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Kevin Wright]

On 19 January 2012 09:20, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:

On Thu, 19 Jan 2012 04:09:06 +0100, Josh Berry <tae...@gmail.com> wrote:

And, again, read what you wrote.  You read massive arrays of
*primitives* into memory.  Now... what if that primitive was an image
and you'd like to treat it as such?  In java, you're hosed.  It is
getting copied to the heap.

Perhaps I didn't understand the point, but in Java you can used memory mapped I/O and have it accessible outside of the heap.

Sure you can.  At least, you can since (the original) NIO landed on our desktops.

You can also quite happily interact with images held in GPU memory, openGL textures are a good example of this.

 

Honestly I have also other questions. I only had a short experience with gaming (from the programming point of view) between 1992-1995, across my primary graduation, when I was writing for fun a flight simulator. It was DOS time, accessing memory beyond 640K was already a problem and I started with a drawLine() getting up to the (gamish) simulation of a US supercarrier getting attacked by a USSR Tupolef Bear. I did all the primitives by myself, also trying alternate ways than the state of the art, and I had things that other games of the time didn't have, such as full 3D cockpits and Doppler effect on digital audio (of course, the application had never been polished enough for being commercialized, since it was just fun). So, I have an idea of what pulling the CPU power from any bit means. But is it today still the same thing? I understand that games are much more complex, but we have specialized hardware for graphics and sound... Are really technical the reasons for preferring C# to Java? Or maybe the reason game developers prefer C# is simply the fact that Microsoft has created since many years a gaming business segment, and Sun just didn't?


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Ricky Clarkson]

Compared to .NET Java has less predictable performance. For example, I wrote a date chooser and my code used quite a lot of anonymous inner classes. The first time the user used that part of the application there was a noticeable delay due to classloading, that I moved to application startup time just so that the user wouldn't see a delay.

It was actually a pretty small delay, less than a second, but in the context of an app that normally responds instantly it was visibly slow.

As I understand it, .NET loads an assembly at a time, not a class at a time.

It does generally 'seem' faster regarding GUI operations, which can be more important than actual number-crunching speed. That applies to Mono too. Work with Eclipse for a day then play with MonoDevelop and you'll probably notice a striking difference in responsiveness.

I have no idea whether MonoDevelop's responsiveness still applies when you have very large projects open; nothing I've ever done in C# hit the 1000 line barrier.

-----Original Message-----
From: clay <clayt...@gmail.com>
Sender: java...@googlegroups.com
Date: Wed, 18 Jan 2012 23:02:32
To: The Java Posse<java...@googlegroups.com>
Reply-To: java...@googlegroups.com
Subject: [The Java Posse] Re: Sony's PlayStation Suite for Vita/Android
Chooses C#/Mono Exclusively. What's the Alternative?

[Josh Berry]

On Thu, Jan 19, 2012 at 4:20 AM, Fabrizio Giudici
<Fabrizio...@tidalwave.it> wrote:
> On Thu, 19 Jan 2012 04:09:06 +0100, Josh Berry <tae...@gmail.com> wrote:
>
>
>> And, again, read what you wrote.  You read massive arrays of
>> *primitives* into memory.  Now... what if that primitive was an image
>> and you'd like to treat it as such?  In java, you're hosed.  It is
>> getting copied to the heap.
>
>
> Perhaps I didn't understand the point, but in Java you can used memory
> mapped I/O and have it accessible outside of the heap.

My impression was that you can do this, but as soon as you pull that
something out of the bytebuffer, it is now on the heap. There are
tricks, of course, you can provide a wrapper around a bytebuffer,
evidently, and always just use getters and setters on the bytes that
you want wrapped. However.... to offer this as some sort of valid
replacement for just being able to define a struct is.... well, a bit
laughable. I mean, Java already gets a reputation for being verbose.
Bean style classes with getters on top of a bytebuffer takes that to a
new level.

> Honestly I have also other questions. I only had a short experience with
> gaming (from the programming point of view) between 1992-1995, across my
> primary graduation, when I was writing for fun a flight simulator. It was
> DOS time, accessing memory beyond 640K was already a problem and I started
> with a drawLine() getting up to the (gamish) simulation of a US supercarrier
> getting attacked by a USSR Tupolef Bear. I did all the primitives by myself,
> also trying alternate ways than the state of the art, and I had things that
> other games of the time didn't have, such as full 3D cockpits and Doppler
> effect on digital audio (of course, the application had never been polished
> enough for being commercialized, since it was just fun). So, I have an idea
> of what pulling the CPU power from any bit means. But is it today still the
> same thing? I understand that games are much more complex, but we have
> specialized hardware for graphics and sound... Are really technical the
> reasons for preferring C# to Java? Or maybe the reason game developers
> prefer C# is simply the fact that Microsoft has created since many years a
> gaming business segment, and Sun just didn't?

Again, just posing the question here is to do so rhetorically. The
reasons are almost certainly partially technical, but not necessarily
because Sun ignored the ball and Microsoft created an environment.
Similarly, there is a reason there were few java applet games compared
to flash. Hell, I struggle to remember any applets of note. There is
certainly no reason java could not have done better there, either.
(There are reasons, but they did not have to be.)

That said, games are much much more complicated than they ever were.
And I'm behind on games. Just really played the first Uncharted game
recently, and even that is enough to convince me that things are
complicated.

[Fabrizio Giudici]

On Thu, 19 Jan 2012 12:14:34 +0100, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Compared to .NET Java has less predictable performance. For example, I
> wrote a date chooser and my code used quite a lot of anonymous inner
> classes. The first time the user used that part of the application there
> was a noticeable delay due to classloading, that I moved to application
> startup time just so that the user wouldn't see a delay.
>
> It was actually a pretty small delay, less than a second, but in the
> context of an app that normally responds instantly it was visibly slow.
>
> As I understand it, .NET loads an assembly at a time, not a class at a
> time.

I know the problem, but isn't this something that can be fixed with a
customized classloader that does preloading and mimics the behaviour of
.NET?

[Carl Jokl]

Judging Java by Eclipse may not be fair as it is fairly bloated as
IDEs go. Perhaps Eclipse vs Visual Studio might be more fair?

That said I Like C# as a language and with Java had unsigned
primitives. I don't see it happening for the sake of compatibility. I
can see stack objects happening eventually given I have been in a
presentation at the London JUG where someone has actually been working
on this already. I am not sure how far into the future it would likely
be though. I think what is going into Java 8 is fairly well
established.

To be honest though. The core game development community seems
standardised on C++. I mean if you are going to criticise Java for not
having many good games I also don't really know any specifically
written in C# .net. I know they must exist but I may not of heard of
any of them. In both cases I imagine more games will have been written
for mobile devices. JavaME and Android have plenty between them. The
latest versions of Windows Mobile will no doubt have plenty examples
of C# games. In the mean time the most popular/recognised games tend
to be C++.

On Jan 19, 11:14 am, "Ricky Clarkson" <ricky.clark...@gmail.com>
wrote:

[Fabrizio Giudici]

On Thu, 19 Jan 2012 13:20:59 +0100, Josh Berry <tae...@gmail.com> wrote:

> My impression was that you can do this, but as soon as you pull that
> something out of the bytebuffer, it is now on the heap.

Correct, but why should you put something out of the bytebuffer? As Kevin
said, a bytebyffer can map e.g. to fast memory such as the video card and
operate there.

> There are
> tricks, of course, you can provide a wrapper around a bytebuffer,
> evidently, and always just use getters and setters on the bytes that
> you want wrapped. However.... to offer this as some sort of valid
> replacement for just being able to define a struct is.... well, a bit

It seems we're shifting the point. I agree that mimicking a struct in Java
is probably laughable, but why should I mimick a struct?

> laughable. I mean, Java already gets a reputation for being verbose.

Verbosity is a different matter than byte code limitations. Here we're
mostly talking about Java-the-VM and not the language.

> Again, just posing the question here is to do so rhetorically. The
> reasons are almost certainly partially technical, but not necessarily
> because Sun ignored the ball and Microsoft created an environment.
> Similarly, there is a reason there were few java applet games compared
> to flash. Hell, I struggle to remember any applets of note. There is
> certainly no reason java could not have done better there, either.
> (There are reasons, but they did not have to be.)

Applets have deployment problems on the internet, but (honestly, I must
admit I've never seen a gaming console) I suppose games are installed as
desktop applications, and there are no problems with that. I'm not saying
that the Sun lack of interest in the segment is the exclusive problem,
but, hell, if you don't push a technology in a segment and your competitor
does, figure out what happens? BTW, for Sony the C# choice couldn't be to
make easier the life for developers that have already large codebases in
C# and want to port to their new consoles?

[Carl Jokl]

I realised one error in my argument i.e. that Visual Studio is not
written in .Net.
I would guess that MonoDevelop is though (I haven't really used it to
know though
I have often installed it as part of Linux and meant to try it out).

[Ricky Clarkson]

Eclipse versus VS still shows Eclipse as slow but VS is a C++ app.

[clay]

"I guess the reason is that Microsoft hasn't sued anybody over their
implementation."

Oracle suing Google over Java in Android is a big deal. I read that
the Oracle side of the story is that Google wanted to do development
in private and periodically release code to the public on their
schedule under a different license which violates the GPL. I may be
wrong and I have very limited understanding of the legal details, but
that doesn't seem insurmountable.

Secondly, if the legal barriers with Oracle really are insurmountable,
you can always use another VM (like LLVM) entirely and a non-Java
language so you really would have no direct ties to Oracle.

"With dogmatism replacing pragamtism over the last 10 years it is not
surprising that many of the more progressive developers left Java-the-
language or even Java-the-ecosystem."

This really depends more on your work environment than the tools
themselves. I look at the Strange Loop conference as kind of a
barometer of the more progressive end of the software development
community, and the Java ecosystem is quite predominant there.

"Calling Maven (and Ant) 'leading edge of the industry', (which is
what about 95% of the developers have to use) is not without irony."

Ant is definitely not the leading edge now, but it was back in the
'90s. Personally, I use Gradle and SBT but even Maven is a giant step
ahead of what you get in the .NET world. I don't have much experience
with Microsoft's TFS, but the Visual Studio auto-generated msbuild/
csproj files are way behind.

"It doesn't help to have superior tooling (IntelliJ or Gradle, SBT)
when no one uses it."

Sure, you have to use a tool to get value from it. It sounds like you
are in an environment where you don't have the flexibility of choosing
these tools yourself. That's more of a workplace issue than a
technology one.

I am jumping the gun on Kotlin. For my game dev dream stack, it's
critical to have a flagship language that is accessible yet provides
significant incremental improvement and excitement upon Java and C#.
Kotlin is a credible candidate but obviously, it's not proven at all.
Scala is definitely a masterpiece from a language design persepctive,
but I'm not sure it is a great fit for game development.

[Fabrizio Giudici]

On Thu, 19 Jan 2012 15:51:44 +0100, clay <clayt...@gmail.com> wrote:

> I am jumping the gun on Kotlin. For my game dev dream stack, it's
> critical to have a flagship language that is accessible yet provides
> significant incremental improvement and excitement upon Java and C#.
> Kotlin is a credible candidate but obviously, it's not proven at all.
> Scala is definitely a masterpiece from a language design persepctive,
> but I'm not sure it is a great fit for game development.

Talking just on the basis of my limited and previously cited experience
with gaming, Scala would be great, indeed (hell, listen who's saying
this!).

I remember that when I had to implement the controllers for many
subsystems (e.g. missiles, but specifically the behaviour of simulated
pilots) I ended up writing a higher level language (too bad I have lost my
original sources, I don't recall the details). At the time it was done
with yacc etc..., which to me is not specifically fun. Today I'd
appreciate the embedded-DSL capability of Scala, because a) I remember I
needed multiple languages (one for each automated weapon, one for pilots,
etc...), and some "plumbing" to map actions of the language to specific
C++ calls. With Scala I could easily embed multiple languages and there
would no need for plumbing, as I coull call original methods. I'm pretty
sure that if I should rewrite that game today, even though I don't like
Scala in general and I'd rather use Java, I'd study Scala at least for the
DSL stuff.

[Kevin Wright]

Scala has one critical disadvantage here, it's hosted on the Java platform and so has to use Java UI implementations.

This can lead to a lot of nasty frustrating things, try dealing with horizontal mouse scroll in Swing for example.  It's really no surprise that Android went and built their own UI layer.

The actual graphics are fortunately not so bad.  Most games nowadays will use OpenGL, and we have a nice OpenGL wrapper available (https://code.google.com/p/scalagl/).  The Scala wrapper for JavaFX 2 is also the closest thing going to the original JavaFX (née FFF) vision, courtesy of the previously mentioned DSL capabilities.  So the situation is most assuredly improving :)

There's also some rather nice support for running logic on the GPU via openCL: https://code.google.com/p/scalacl/, thanks to the extensibility of the compiler's plugin architecture.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Fabrizio Giudici]

On Thu, 19 Jan 2012 16:39:50 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> Scala has one critical disadvantage here, it's hosted on the Java
> platform
> and so has to use Java UI implementations.
> This can lead to a lot of nasty frustrating things, try dealing with
> horizontal mouse scroll in Swing for example. It's really no surprise
> that
> Android went and built their own UI layer.
>

There's the new JavaFX 2.0, which I suppose Scala can use without problems.

[clay]

"Scala has one critical disadvantage here, it's hosted on the Java
platform and so has to use Java UI implementations."

Regardless of language, any decent console/smartphone game dev stack
is going to go straight to OpenGL or something similar. Scala can do
this, as can just about any language.

Swing, JavaFX, and WPF/Silverlight are mainly for component
applications made of checkboxes, text boxes, buttons, and grid
controls... No game developer would ever use these things. The JavaFX
team is delusional if they think game devs will code to a scene graph
made for business apps rather than a low level OpenGL context.
Silverlight, btw, is widely misunderstood: 99% of the Internet knows
of Silverlight as a HD video player and has never used another
Silverlight/WPF application. On the developer side, Silverlight and
WPF are basically exactly the same thing and comparable to Swing or
JavaFX.

"BTW, for Sony the C# choice couldn't be to make easier the life for
developers that have already large codebases in C# and want to port
to their new consoles?"

Their primary professional SDK is still C/C++ only. It's their
forthcoming hobbyist SDK that is C# only. And the target hobbyists
have minimal legacy concerns. Secondly, C# is on the level of Java in
being extremely rare for game development. C# just got two big boosts
to game development: Google Native Client and this forthcoming
PlayStation Suite.

I'd estimate in order of popular to less popular, for games you'd
have: C/C++ > Flash > Lua > Objective-C (iOS) > C#/Java.

"there is a reason there were few java applet games compared to flash"

The era of Flash is coming to an end. Consumers have partially
migrated to iOS/Android which are mostly plugin free, and even Win/Mac/
Linux users are becoming more resistant to installing a separate
system level runtime like Java/Flash/Silverlight. The genius of Mono
is that it's completely integrated into the game itself and completely
invisible to the end user. The big failing of the Java community is
that they have yet to match that deployment story.

[Fabrizio Giudici]

On Thu, 19 Jan 2012 20:29:23 +0100, clay <clayt...@gmail.com> wrote:

> "Scala has one critical disadvantage here, it's hosted on the Java
> platform and so has to use Java UI implementations."
>
> Regardless of language, any decent console/smartphone game dev stack
> is going to go straight to OpenGL or something similar. Scala can do
> this, as can just about any language.
>
> Swing, JavaFX, and WPF/Silverlight are mainly for component
> applications made of checkboxes, text boxes, buttons, and grid
> controls... No game developer would ever use these things. The JavaFX
> team is delusional if they think game devs will code to a scene graph
> made for business apps rather than a low level OpenGL context.

I don't expect the core of a game to be made in JavaFX, but what about
menus, configurations, etc?

[clay]

On Jan 19, 5:14 pm, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:

> I don't expect the core of a game to be made in JavaFX, but what about
> menus, configurations, etc?

Even that stuff is heavily customized in games, so no.

Look at a great Java game like Wakfu. Can you imagine Wakfu dropping
into Swing/JavaFX for a config menu?

Or a popular C# game like Bastion: Would that drop into WPF/
Silverlight for a config menu?

Absolutely not.

JavaFX 2 also has a cleaner, legacy free (no AWT) browser plugin and
windowing system. I'd like to think that stuff can be used for an
OpenGL game. I remember reading a JavaFX team member saying that if
you still want to make your game in OpenGL and not use the FX scene
graph, then they have failed in their goals... I think they are
choosing the wrong battle.

BTW, I'm one of the few people who has done WPF programming,
Silverlight, and JavaFX (also Swing, C# WinForms, and a ton of
Microsoft C++ MFC, and even Macintosh Classic PowerPlant). I think
JavaFX is the best of them, but it's a really shrinking space. Very
few people are are making or using those type of workstation desktop
apps any more: GUIs today are almost always either web or mobile.

[Kevin Wright]

Possibly you'd see menus, etc. done in whatever windowing toolkit were available.

Graphics weren't my concern though, input devices were.  I've had a nightmare in the past trying to handle e.g. horizontal scroll and more than 3 buttons on a mouse under swing, eventually gave up on it as being impossible.

SWT was better here, but came with a different set of issues.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

On Thu, Jan 19, 2012 at 3:37 PM, clay <clayt...@gmail.com> wrote:

I remember reading a JavaFX team member saying that if
you still want to make your game in OpenGL and not use the FX scene
graph, then they have failed in their goals

Seriously? They said that?

I don't know how much out of touch they can show to be.

Not that there was any doubt considering JavaFX' track record in its five years of existence.

-- 

Cédric

[Fabrizio Giudici]

On Fri, 20 Jan 2012 00:37:07 +0100, clay <clayt...@gmail.com> wrote:

> few people are are making or using those type of workstation desktop
> apps any more: GUIs today are almost always either web or mobile.

... guys making web or mobile apps are making web or mobile apps. Guys
making industrial apps are mostly making desktop apps. I think that JavaFX
2.0 is for this, and - apart my previous question - I didn't think it
could be used by core game programmers.

[clay]

On Jan 19, 5:46 pm, Cédric Beust ? <ced...@beust.com> wrote:

> On Thu, Jan 19, 2012 at 3:37 PM, clay <claytonw...@gmail.com> wrote:
> > I remember reading a JavaFX team member saying that if
> > you still want to make your game in OpenGL and not use the FX scene
> > graph, then they have failed in their goals
>
> Seriously? They said that?
>
> I don't know how much out of touch they can show to be.

Here is the exact link:

http://www.java-gaming.org/topics/early-reports-on-javafx-2-are-in/23790/msg/198847/view.html#msg198847

"My name is Joe and I am one of the main engineers working on Prism."

"If you have to resort to using JOGL, then we have failed. The idea is
that the JavaFX api's provide you with enough stuff. Granted, for a
full 3d game, we aren't there yet."

"remember prism implements javafx on ogl and d3d."

To summarize: The JVM needs a better deployment story to attract game
developers. If people could write an OpenGL game in Java/Scala/Kotlin
and deploy to Win/Mac/Linux users *without* the end user having to
install/maintain a system level Java runtime and port the same
codebase into something that can run on Android and iOS and, in a
dream world, PlayStation Vita or Google Native Client, that would be
*huge*. It would take the industry by storm.

Oracle building their own scene graph and rendering engine on top of
OpenGL, like JavaFX 2, is the complete wrong direction. Leave the
OpenGL game engines up to the game engine crowd, like Ogre 3D, Unreal
Engine, Torque, etc. Game programmers are absolutely *fanatical* about
that specific piece of the stack: they are notorious for reinventing/
rewriting that themselves. I really don't see any interest or benefit
in Oracle making an competing entry in this spot of the stack.

But the runtime and deployment issues? That's the piece game
programmers want someone else to do.

Take an example: Battlefield 3. They made their own graphics engine
that sits on top of an OpenGL type layer, and named it the Frostbite
engine: In the ads, they give this top billing just like a movie would
give top billing to a star actor or director. They are fiercely proud
of that. If anyone thinks this type of studio would trade that in for
some Oracle API, you are out of touch. OTOH, if you could give them
access to exciting programming languages (Scala/Kotlin), amazing IDEs
(IntelliJ), best of breed build tools (Gradle), and let them reach
their player base on workstations/smartphones/web browsers/game
consoles, they would be floored.

[Cédric Beust ♔]

On Thu, Jan 19, 2012 at 7:51 PM, clay <clayt...@gmail.com> wrote:

If people could write an OpenGL game in Java/Scala/Kotlin
and deploy to Win/Mac/Linux users *without* the end user having to
install/maintain a system level Java runtime and port the same
codebase into something that can run on Android and iOS and, in a
dream world, PlayStation Vita or Google Native Client, that would be
*huge*. It would take the industry by storm.

I'm really not convinced because they would have to add significant value to what's available today and what's about to be available even at the Javascript level (check out Three.js for example). JavaFX is five years old and one of the main engineers is saying "we're not there yet".

They are not just behind technically, they are behind in terms of skills and vision.

This won't end well.

-- 

Cédric

[clay]

Those Three.js demos are awesome, particularly the WebGL stuff.

The embedded runtime solution I'm proposing would absolutely add value
on two major points.

1) Better programming languages and associated tooling. JavaScript is
so popular because it's absolutely universal on the client side, but
developers pretty much universally prefer other languages. Static
languages in particular lend themselves to far better tool support.
Additionally JavaScript has a terrible modularity story when it comes
to using third party libraries.

2) Runtime performance. This is huge. That was the biggest gripe about
the JVM in this thread. But the JVM performance is an order of
magnitude better than what you get on JavaScript even with the new
generation of super browsers and cutting edge JavaScript runtimes.

Those WebGL demos look awesome, but notice that they mostly show
single scene rendering that is happening predominantly in the native
OpenGL layer just like a C/C++ game or a Java game with JOGL like
Wakfu. When you need to add scene level processing or AI/physics/game
logic on top of that, then you start to see the impact of JavaScript.

The JVM runtime delivers performance much closer to C/C++ than
JavaScript.

If you want evidence, read this, which does some physics engine
benchmarks on C/C++, Java, and JavaScript (in all major browsers):
http://blog.j15r.com/2011/12/for-those-unfamiliar-with-it-box2d-is.html

These two issues are just too large to stick with JavaScript for games
and similar intensive 3D applications.

"This won't end well."

JavaFX 2's adoption among game developers won't end well. But overall,
the options for developers and users are super bright. I'd just like
to see the more exciting parts of the Java ecosystem (tooling + alt
languages) connected to it.

Google has a much better finger on this issue as you can see with NaCL
and WebGL and even Dart (I'd way prefer Java/Scala/Kotlin/Clojure).

[Casper Bang]

For some reason, the discussion went offline from this group, so let me repost my latest response to Clayton:

> For myself, I'd like to see an alternative to Mono and C# for things like
> PlayStation hobbyist development, and I don't believe that runtime
> performance is a significant barrier to the JVM being used for that.

Fair enough. There is no doubt that the JVM is uber-optimized and, for
a large class of tasks, it is awesome at what it does once it's warmed
up. I'm just... less interested in the runtime engine itself and
ideally would just want to replace Mono with Dalvik, JVM, Parrot...
you name it.

> I don't understand this. How does Mono assist in using code from other
> languages?

Are you a *NIX/POSIX guy and know about libc? Say you have a need for
doing fast base2 logarithms (not native in java.util.Math package nor
System.Math namespace. In C#, you can encapsulate libc's
implementation easily doing something like this:

class ExtendedMath
   {
       [DllImport ("libc.so.6")]
       private static extern double log2(double);

       public static double Log2(double arg)
       {
           return log2(arg);
       }
   }

You wouldn't believe the horrorshow of doing this via JNI, using javah
to generate header files, add these to the projects build path, write
wrapper in C/C++, write wrapper in Java using System.loadLibrary(). In
other words, while the JVM/Java is about *platform interoperability*,
the CLR/C# is about *code interoperability*. As someone who lives in a
heterogeneous world, recognizing that some tools/languages are better
than others for a given task, I rather like code interoperability.

> This is one issue I really strongly disagree with you about. Both the JVM
> specification and the JVM software implementation are completely malleable
> entities. Absolutely every line of code in that JVM can be changed for
> future versions. The premise that some past design decisions of the JVM
> somehow prevent you from adding features like this for future versions is
> unreasonable. Some changes impose backwards compatability costs or various
> other costs, of course, but most things can be changed.

Nothing you've said above, serves to contradict what I say or convince
me that I am wrong. Fact: To support multiplication, the JVM specifies
imul, lmul, fmul and dmul instructions (same overhead for addition,
subtraction, division, modulus, negation, load, store etc.) and there
simple aren't enough instructions left of the 255 available, to do
this in a backwards compatible way. I'd like to be proven wrong, but
changing binary backwards compatability is extremely unlikely scenario
among the conservative gang of Oracle developers.

[clay]

On Jan 20, 5:21 am, Casper Bang <casper.b...@gmail.com> wrote:

> Nothing you've said above, serves to contradict what I say or convince
> me that I am wrong. Fact: To support multiplication, the JVM specifies
> imul, lmul, fmul and dmul instructions (same overhead for addition,
> subtraction, division, modulus, negation, load, store etc.) and there
> simple aren't enough instructions left of the 255 available, to do
> this in a backwards compatible way. I'd like to be proven wrong, but
> changing binary backwards compatability is extremely unlikely scenario
> among the conservative gang of Oracle developers.

Adding new instructions, removing the 255 instruction limit, or even
switching to a completely brand new instruction set entirely wouldn't
break backward compatability at all. It would break forward
compatability. To use a made up example, let's say Java 9 added 100
new instructions. Backward compatability would mean that the Java 9 VM
could still understand Java 1-8 bytecode; of course it would! Forward
compatability would mean that the older VMs would understand the new
bytecodes; this generally doesn't work. Software projects do stuff
like this every day.

Regarding the C library access, sure. I said exactly that earlier in
this thread. C# provides much easier native code integration (often
called FFI) than Java does with JNI. That's my impression although
I've never used JNI directly; but I've used wrapper libraries like
JavaCL/JOGL. I've heard Lua also does this exceptionally well, which
is why it's so popular in video games. In my years of C# development,
we did this quite a lot in the early days when the .NET libraries were
immature and you had to call Microsoft Win32 APIs in C for various
things. Now, it's more of a performance thing for non-standard inner-
loop type functionality.

The legal issue is a big deal. Most of us aren't deeply knowledgable
(or interested) in the legal nitty gritty of this, but if someone
really were to make a PlayStation JVM type product a reality, it would
be extremely critical to research and understand this issue
thoroughly. Ultimately, even in the worst case scenario where you
can't use any Oracle related tech without major lawsuits, you could
still find another legally safe VM, whether it's one of the dozens of
alternate Java VMs, or jump to something completely separate like
LLVM.

The Oracle lawsuit against Google over Java is worrisome. And Oracle
doesn't come across as the nice guy; I know their argument is that
Google wanted to use GPL open source Java code and effectively take it
semi-closed source where they do development in private and release
code to the public on their schedule. That actually makes sense, but
their interests seem so aligned, I can't believe they couldn't come to
a reasonable agreement. But in some ways, Microsoft is more worrisome,
in that they are lot better at winning lawsuits against competitors
who aren't even using their products. Android made a better product
than they did, and Microsoft is able to use larger teams of fancy
lawyers, and buy enough legal and political influence, to force a
completely separate competitor to pay them money! Sure, they didn't
sue Mono; they love the Mono team, the two have had a happy
partnership, and they provided funding for the Mono team. That doesn't
say much.

[Cédric Beust ♔]

On Fri, Jan 20, 2012 at 3:21 AM, Casper Bang <caspe...@gmail.com> wrote:

You wouldn't believe the horrorshow of doing this via JNI, using javah
to generate header files, add these to the projects build path, write
wrapper in C/C++, write wrapper in Java using System.loadLibrary(). In
other words, while the JVM/Java is about *platform interoperability*,
the CLR/C# is about *code interoperability*. As someone who lives in a
heterogeneous world, recognizing that some tools/languages are better
than others for a given task, I rather like code interoperability.

Indeed. It never ceases to amaze me that Microsoft solved the multilanguage problem in 1995, and nobody has come close to that even today. Writing a function in language X and using it in language Y was a reality on Windows platform more than fifteen years ago and even more so today.

-- 

Cédric

[Jeb Beich]

Hasn't writing a function in language X and using it in language Y been a reality on the Java platform for a while now?

2012/1/20 Cédric Beust ♔ <ced...@beust.com>

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Jeb Beich
http://www.red-source.net/jeb

[Simon Ochsenreither]

You could think otherwise after reading the mailing list. :-)

[Cédric Beust ♔]

On Fri, Jan 20, 2012 at 10:25 AM, Jeb Beich <jebb...@gmail.com> wrote:

Hasn't writing a function in language X and using it in language Y been a reality on the Java platform for a while now?

It's not a reality even if you limit the claim to languages that only run in the JVM.

COM goes way, way further than that. What Microsoft saw that nobody else did is that the important part is the ABI, not the API.

-- 

Cédric

[clay]

You are saying that the JVM doesn't foster cross-language interop even
among JVM languages? The team I work on has been using interop between
various combinations of Java, Groovy, Clojure, and Scala all the time.
What is missing?

COM? I spent thousands of hours mastering COM, and the OLE framework,
and ActiveX components. At the time, people believed that those were
the key career skills for the future. In hindsight, those technologies
were horrible. I've never met anyone who felt otherwise.

On Jan 20, 1:45 pm, Cédric Beust ♔ <ced...@beust.com> wrote:

[Isaac Gouy]

On Jan 17, 10:57 pm, clay <claytonw...@gmail.com> wrote:

> Just googling, I found what looks like a pretty meticulous and up to
> date programming language benchmark site:http://shootout.alioth.debian.org.
> C++/G++ is faster than Java which is faster than C#/Mono. And the gap
> between Java and Mono is larger than the gap between Java and C++.
> It's a Debian site so they don't have data for Microsoft's .NET
> runtime which is Windows-only.


http://shootout.alioth.debian.org/demo/compare.php?lang=csc&lang2=csharp


http://shootout.alioth.debian.org/help.php#win32

[clay]

Isaac, I included the correction you emailed me, with the Windows C# +
Java 7 benchmark link way back in this thread. I said:

On Jan 18, 2:39 pm, clay <claytonw...@gmail.com> wrote:
> Someone privately messaged me this link:http://shootout.alioth.debian.org/demo/benchmark.php?test=all&lang=cs...
>
> That's the same suite of comprehensive benchmarks but compares Java 7
> to C#/.NET (Microsoft's implementation as opposed to Mono) running on
> Windows.
>
> Java 7 comes out as quite a bit faster.
>
> This coincides with my personal experience of benchmarking key pieces
> of software that I'm working on and comparing Java 7 to C#/Microsoft
> on my Windows laptop.
>
> So Java 7 is faster than C#/Microsoft which is faster than C#/Mono. I
> assume this is due to a more polished/tuned VM rather than a language
> level feature difference.

[Vince O'Sullivan]

On Jan 18, 4:07 pm, Isaac Gouy <igo...@yahoo.com> wrote:
> On Jan 17, 10:57 pm, clay <claytonw...@gmail.com> wrote:
>
> > Just googling, I found what looks like a pretty meticulous and up to
> > date programming language benchmark site:http://shootout.alioth.debian.org.
> > C++/G++ is faster than Java which is faster than C#/Mono. And the gap
> > between Java and Mono is larger than the gap between Java and C++.
> > It's a Debian site so they don't have data for Microsoft's .NET
> > runtime which is Windows-only.

Statistics like these are more or less meaningless in the real world.
In practice, the only thing that counts is the quality of the
programmers.

[Casper Bang]

I spent 10 minutes cooking up 2 naive implementations of finding primes between 1 and 10^7 in both C# [http://pastebin.com/RDGQZPAr] and Java [http://pastebin.com/JpY8FsA1], and the result is that C# is faster:

Java: 664579 primes were found in 8262 ms

C#: 664579 primes were found in 7698.878 ms

...using default configurations for JDK7 (Server HotSpot) and Mono 2.10.5 JIT on my 64bit Ubuntu workstation. It's pretty simple CPU work with method invocation within iteration, some increments/adds, a bitwise-operation, a library call, modulus and of course branching/comparisons.

Now notice what happens when I change the type from long to ulong (unsigned long) in C#:

C#: 664579 primes were found in 5651.8524 ms

It's my experience that C#'s extra features (in this case, unsigned types) just caters better to programming into the language, not in it* and more predictable performance. In other words, the JVM JIT might be superior to Mono's, but that's hardly the whole story!

* Steve McConnell, Code Complete.

[clay]

Just pasting your examples into a new NetBeans project and a new
MonoDevelop project, I can't reproduce your results. I ran this on
Windows, and I think MonoDevelop might be using .NET runtime rather
than the Mono runtime (I don't know - I also had to convert StopWatch
to DateTime to get it to compile):

JDK 7/Windows
664579 primes were found in 10628 ms

C#/Windows
664579 primes were found in 12505 ms

C#/Windows (find/replace all long to ulong)
664579 primes were found in 10642 ms

This concept of the embedded micro VMs is really something that I
think it is important for the Java community to understand and
discuss. That's my main reason for posting and discussing.

I'm less interested in debating with C# fanatics. Two others in this
thread are insisting that Java runtime performance is a big
showstopper. After looking at benchmarks, Java is actually running
faster than C#, but I don't really want to debate that, I'm more
interested in promoting a major improvement to client Java.

[Casper Bang]

On Wednesday, January 25, 2012 1:42:31 AM UTC+1, clay wrote:

Just pasting your examples into a new NetBeans project and a new
MonoDevelop project, I can't reproduce your results. I ran this on
Windows, and I think MonoDevelop might be using .NET runtime rather
than the Mono runtime (I don't know - I also had to convert StopWatch
to DateTime to get it to compile):

Then you are using an old version of .NET and that's hardly fair in a state of the art comparison.

 

 

I'm less interested in debating with C# fanatics. Two others in this
thread are insisting that Java runtime performance is a big
showstopper. After looking at benchmarks, Java is actually running
faster than C#, but I don't really want to debate that, I'm more
interested in promoting a major improvement to client Java.

And I tried to show you, how a richer programming model and runtime environment, better allows people to model their problem domain and gain performance. You were the one bringing up the whole subject of benchmarks after all, on several occations even I'm not a C# fanatic btw., I simply see some obvious (and unfixable) flaws with Java and how things have traditionally been done. Coincidentally, Java is now gaining support for unsigned integers [http://blogs.oracle.com/darcy/entry/unsigned_api] but it's little more than syntax sugar (MSB semantics adapter).

[clay]

> Then you are using an old version of .NET and that's hardly fair in a state
> of the art comparison.

This was my fault, I just copied the contents of the class and missed
the using statements. Once I added System.Diagnostics, Stopwatch works
fine (this doesn't affect performance). But I'm definitely using .NET
4.

> Coincidentally, Java is now gaining support for
> unsigned integers [http://blogs.oracle.com/darcy/entry/unsigned_api] but
> it's little more than syntax sugar (MSB semantics adapter).

From looking at the patches, it doesn't look like they are adding real
unsigned integer data types, but rather adding system library
functions to interpret existing signed primitive types as unsigned
values. I'd presume that may lead to limited performance gains if the
VM adds special optimizations on top of the Java source code
implementation.

[Casper Bang]

For completeness sake, the C version [http://pastebin.com/0TDYDR3r] of the algorithm yields a result of 3.872 sec with default settings using GCC 4.6.1 (x64 architecture, C99 mode). So much for Java supposedly being faster than C.