Hacker News Reader

> I chuckled at this: "In schools and colleges that use Office 365, students will be able to log on to Minecraft using their Office credentials." Because everyone things "how can I log into this game? Oh yeah, with my office credentials." :-)

I know this was meant to be a joke, but this was more an issue in wording by Schofield (the writer) than anything else. A Microsoft account is pretty much global across all their products. So it's also their email account, their OneDrive account, their Azure account... I'm assuming he picked Office 365 simply because that's the product he thinks is most likely to be already used in the school.

As for the optimization; the JIT's main optimization from what I've researched is inlining. Which is really beneficial for Java because you tend to end up with a nest of getter method calls all to get a single field somewhere, and wouldn't it be nice if the JIT could just inline that field for you? I suspect that, especially if performance is at stake, it's less typical to end up with patterns like that in a C++ codebase.

Yes, this is a good strategic move by Microsoft. All of my kids have Google apps accounts that their schools set up for them. They are required to use Google docs, etc., so they can work on stuff at school and at home. I assume that a good portion of those kids will continue to use Google apps as a default for a long time. Similar to a strategy Microsoft used to keep Office a standard: the dirt-cheap student version.

If Microsoft can get schools to use Office 365 instead of Google apps, then $2.5 billion for Minecraft was cheap.

Sure but first MS needs a Google Classroom competitor because that's probably the other major Google product that schools are using.

> I chuckled at this: "In schools and colleges that use Office 365, students will be able to log on to Minecraft using their Office credentials." Because everyone things "how can I log into this game? Oh yeah, with my office credentials." :-)

If you're a teacher, it's a huge boon to be able to re-use existing accounts. You really don't want to make dozens of classes of kids set up and remember new IDs and passwords for a single application.

To be honest, a lot of people have slammed the Minecraft codebase, claiming it's badly written and kind of a slow mess. I can't recall the citations, but based on the discussions when I read those aspects, I wouldn't put aspersions on Java alone in this case.

It was a one-man hobby project turned into one of the biggest video games. I doubt many codebases would work well after growing so far past their original aspirations.

It was never well-written, though. It was good enough to work, but it was never good code.

But it got the job done. That means way more than whether he used a factory or not.

I remember when I played it, there were many mods that optimized the game, usually offering over a 10x speedup with no noticeable difference in graphics or detail.

I definitely think that most of the speed increase is coming from the fact that Minecraft is being rewritten, and not which language it's being rewritten in.

I remember reading a blog post where somebody talked about how they severely decreased Minecraft's performance after refactoring and replacing function calls with separate X, Y and Z parameters to using a single Position object, which would of course in many instances have to be allocated on the fly. I can't seem to find it anymore, though.

Yes, something that should have at a minimum caused no harm to performance (and possibly helped, such as by allowing for SIMD) and been a win for code readability instead introduced an extra layer of pointer chasing and heap allocation, because Java doesn't have structs. See https://news.ycombinator.com/item?id=8485180

Indeed. They are adding value types though. It'll take years but once done, this kind of problem shouldn't crop up again. They've also been doing work on better escape analysis.

The JVM can do a lot of optimisations C++ apps don't benefit from, but I think the loss from not having value types more than drowns them out.

That's the one, thank you.

Sometimes you just have to get things done. The world probably wouldn't have Minecraft if the author had worried about "the proper way to architecture java code" that he read on some ranty blog somewhere.

Version 1.0 is always more sloppy than version 2.0, because with version 2.0, you have the luxury of 20/20 hindsight.

The real reason for chuckling here is the implication that anyone would use O365 for personal use. I'm stupid enough to use it and have almost decided to write-off the money I paid and go elsewhere. This is what $70/yr gets you:

1. ActiveSync! This is the only reason I'm still putting up with this garbage.

2. My company also uses O365, extensively. We have a wiki of sorts in OneNote. I can't contribute to it. Logging into the corp account and clicking "open in desktop" results in an error that claims that I don't have a license. I do. On an on-premise licensed domain-joined machine. I don't on my own O365 account but I didn't log on with that.

3. No layman interface. Want to disable password expiry for your 89yr old father? You'll need to download and install a powershell plugin before you can start reading documentation.

4. Inexplicable login problems. No UI to enter my login email because I had logged into a temporary SP online site I was debugging with. Later I found a "forget this login" link under the temporary login; restoring my access to any other account.

5. "Live login? Microsoft login? We don't know, tell us every time. Oh! You can't use Live with this service anyway!" I no longer know which of the two accounts my stuff is on.

TLDR; O365 is great for corporate/business. I'd recommend it. For personal stuff stay the hell away. They really want to give O365 to kids?

They're giving it to /schools/. Schools have pretty much the same needs as corporations/businesses, in terms of security levels, etc.

But usually only 1/10th the budget for people to run it. I've set up both O365 and Google Apps for schools, Google LDAP sync is way easier to work with, although the syncing of passwords is harder. MS's AD sync is complex, and ended up filling one server with debug log files.

What the author means, and is significant for the market (Minecraft Education Edition) is that it will work with any "Azure Active Directory" credentials. Every school I've worked with either uses active directory or has another directory service that exposes endpoints (usually SAML based).

Read that line instead as:

Good news! Your teachers and their students won't need yet another password to be able to use this application.

I read somewhere that it was a religious issue not providing AOT compilation.

It always saddned me not to have this option in the reference JDK, only on commercial JDKs.

Whereas we already had Java like safe languages with Eiffel, Oberon and Modula-3 compiling AOT to native code, and with JIT also available before 1996.

Oh and with value types and proper generics as well.

Now maybe Java 10 will become what Java 1.0 should have been.

They're adding AOT compilation to Hotspot.

However it'll be a commercial feature. The main reason being, they think it only really matters to rich trading houses that want to hit full speed when the market opens at exactly 9am. The tricky part is that there'll still be JIT compilation happening, because otherwise the program runs quite a bit slower, as the adaptive optimisations can make a big difference.

I saw the JLS 2015 presentation about it.

Which is sad, because if I want to pay for it I don't need to wait for Oracle, almost all comercial JVMs already do it.

When I got into Java, I always expected it to eventually support AOT on the standard compiler.

Right now many trading houses with huge IT budgets are choosing Java for their high frequency trading systems. This is an arena where microseconds matter and the fact that Java is a viable choice, says a lot about the speed and power of modern Java.

Actually, they've moved beyond that now. The trend in high speed trading is towards FPGAs. "Java don't play that." (not in any serious way).

Java in finance is actually slowly eroding overall. Performance-critical logic is being moved into Python modules written in C. "That's how we do it" anyway. The trouble is that Java code development is too slow and just getting your code deployed into a test environment is often ridiculously complicated (lots of middleware) whereas with Python "you write, you run, you're done."

It's still popular. For example, LMAX still uses Java. There were a number of things you needed to avoid if you wanted to use it where latency mattered though. GC pauses are fairly detrimental.

Where latency is really critical, things are implemented in FPGA though.

Although I guess that is telling that one of LMAX authors (Martin Thompson) has moved back to support C++ alongside Java on his newer product.

http://mechanical-sympathy.blogspot.de/

I guess C++ progress in the last years has helped this.

Even before 0x, a there was definitely a genuine performance need that drove a lot of stuff from Java to C++. A lot of people I know would write Javaish code with Boost.

A lot of the stuff that makes Java great for building high level systems quickly is still kind of missing from formal C++ though (IoC, JMX, etc...), and it would have been nice to see some of the internal stuff get open sourced.

I wonder if people are starting to avoid Java because of Oracle (e.g. vs Google).

Before 0x, Java didn't matter for production code as the 1.3 with JIT came later than that.

But in those days it was a big mess to write portable C++ code, given the discrepancies between compilers.

I don't miss those CORBA and DCOM libraries, but I miss OWL and VCL.

Java is still quite strong in the Fortune 500, and most managers don't care about Oracle vs Google, as it was caused by Google trying to avoid to pay Sun anyway.

However I sense some signs similar to when CA started loosing CLIPPER's direction, or when Borland attitudes started scaring people away from Delphi and C++ Builder.

On the other hand, Java is just too big and it will take generations to replace all those systems.

The earliest version of Java I worked with in production was 1.5, but the group I was working with had been using it in production a long time before that. There were other groups using Java for a lot of other things (JDBC, JMS, etc...). All the stuff I worked with relied on core Java and NIO though, which I'm not entirely sure how a lot of things were done before 1.5.

Java is definitely still really popular for development overall (TIOBE 2015 #1). My personal concern with Oracle vs. Google though is that Oracle does not own the language, and the copyright claim on APIs seems pretty aggressive. The JVM and Java have open specifications which in theory anyone should be allowed to implement (practice is admittedly a bit different). Even the official JDK was open source, which Oracle seems a bit hostile toward considering what they've done with purchases like MySQL and how the community largely responded.

Claiming copyright on an API seems somewhat akin to Keurig 2.0. Although, I think courts are having trouble keeping pace with technology.

I have been using occasionally Java since it was made available in 1996.

Our university adopted it right away and made it in 1997 the official language for compiler development and distributed systems classes.

Without bothering to search the Internet, NIO was either introduced in 1.4 or 1.5.

Yes they have open specifications, but they also have trademarks and compliance certifications.

The JDK was open source, but the license prevented its use for mobile devices without a Sun approved license, that Google didn't want to pay for.

So now Google has actually created a fork in the Java community.

Just imagine when you have Java 9 with modules, or Java 10 with reiffied generics, value types, JNI replacement, official unsafe package, among many other roadmap features, how to keep the code portable between Android Java and the real Java.

You are right, but google is moving to OpenJDK. This will fix those problems, or did I misunderstand what the implications of this move will be? http://venturebeat.com/2015/12/29/google-confirms-next-andro...

edit: The article does state at the end that google will still modify OpenJDK for their own needs, but that still means that the vast majority of the implementation will be the same, so this seems to avoid most incompatibility issues.

Thanks, I actually missed this. The difference with modifying OpenJDK is that it's a common codebase as opposed to a language fork.

I know Redhat is one of the other major OpenJDK contributors, and a lot of distributions are relying on IcedTea. It will be interesting to see how this develops.

So far Google has adopted parts of OpenJDK 7.

They still don't tell anything about newer versions.

NIO was 1.5. Before that, a lot of network programming wasn't practical where performance was a concern. I would guess it was the same with Linux before 2.6.

Boost Python is great for C++ shops too.

Not that it's a fair comparison, but I wonder if you took a Java from today and compared it to a C++ compiler from then, would the optimization differences make Java faster for a larger subset of algorithms? I wonder if this was just the classic problem of assuming your competition is static, and planning to eventually surpass their current capabilities while ignoring that by that time their capabilities may have evolved as well.

Nope, it has to do with the fundamental memory models of Java vs C/C++.

In C++ you can arrange your access patterns so you don't cache miss, much harder to do that in Java.

Harder to do manually, or harder to do even for the VM (given enough intelligence) because of the memory model?

You can do it by treating everything as a ByteBuffer, but then you pay some conversion costs(Int -> Float is esp painful).

It's fundamentally a data structure + execution flow problem so it's not something that a VM/compiler can help with. The fact that everything in Java is a ref(to be fixed some point in distant future) just means that every object fetch is a cache miss(really bad).

Around Java 7, there was experimental support for scalar interpolation. I'm not sure how it progressed though.

Ah, that makes sense.

So, we could conceivably claim that if that is fixed, Java might be able to JIT compile run code a bit faster than C++ in a wider application that currently, but then again by the time that happens, C++ might have a plethora of other tricks up it's sleeve to make execution a little faster.

You're hypothesizing something that really wouldn't be Java anymore.

Isn't this what Dalvik does? (And by extension, ART)

IIRC, a register-based virtual machine would alleviate the cache-miss behavior the GP talks about. (Because larger, more complex instructions = fewer hits to cache)

It's been a while since I've mucked around with this type of stuff, though.

Nope, you're thinking a one level too low in the stack.

The issue is that each object is a reference, and because it's a reference it's position in memory is by nature ambiguous(compacting GCs make this even worse by moving things around).

Until you can guarantee memory location you don't know that the N+1 object you're going to access is in the same cache line(or prefetched) and any sort of cache optimization is shot to hell. Only by knowing your standard execution flow and data set size can you write code that's as efficient about cache misses as possible.

Hotspot only tends to focus on tight inner loops where the stuff I'm talking about involves looking at the larger program(and the structures you choose to put data into). Think Structure of Arrays(SoA) rather than Arrays of Structures(AoS). Possible to do in Java, but very painful.

Not only that, but IIRC at the beginning each ref was a pointer into a table that would store the actual address of the object. So every ref was a double pointer dereference.

Java JIT is the state of the art, in most generated code is _only_ 50% slower despite totally wrecking cache/memory locality.

True, but it will hopefully change in Java 10.

Given the ~3-5 year release cycle trend(plus the fact that android is still Java 7) I'm sure we can expect it by 2025 ;)

Most likely Google will never update beyond Java 7, if their attitude at Google IO is anything to go by.

For me what counts is the official Java, not forks.

They've already updated to Java 8 with the switch to the OpenJDK so whenever Java 9, 10, 11, etc come out they'll be in sync.

I have news for you.

Check the Android source code.

They updated to selected parts of OpenJDK 7!

>So it really doesn't surprise me that a C++ version of Minecraft would out perform a Java version

I am not sure it is a fair comparison. had Minecraft been written in C++ with the same dev cycle, a complete rewrite in Java would also allow to improve its perfs ...

Compiled versions of Java libraries and apps would ruin the whole ecosystem and basically the best thing about Java. The CLR is a good compromise but in the end its not that much better.

Hindsight is always 20/20 so it really doesn't surprise me any rewrite is faster than the previous version.

Not that I prefer Java where performance is important, but profile based optimization combined with optimizing across translation units is non-trivial. C/C++ compilers have been increasing support for these more recently. Jan Hubicka's blog has a good example [1].

I have to wonder if they plan to keep the codebase portable though. One of the major benefits of Java was that nearly everything has a JVM.

[1] http://hubicka.blogspot.com/2014/04/linktime-optimization-in...

> One of the major benefits of Java was that nearly everything has a JVM.

This was a big deal in the late 90's as C compilers were still catching up with ANSI C and ANSI C++ wasn't done, with each compiler supporting a different flavour of the ongoing work.

I would guess a lot of stuff wasn't completely POSIX either (still kinda true). It's really only recently C++ added a standard memory model, portable threading, etc... POSIX is even kind of falling behind for this stuff IMHO.

POSIX is basically what should have been the official C runtime, but they didn't want to make it a richer runtime.

At least as I see it.

> That aaid, one of the more interesting debates I participated in at Sun was Bill Joy's insistence that interpreted Java would be "faster than C++."

Today, with JDK8, that's almost true. With JDK9 it might be.

There's no reason Java can't be faster, it just hasn't happened yet.

Stunning that Bill Joy ever thought interpreted Java could be faster than C++. I thought he knew more than that...

He may have simply overestimated the availability of Bill-Joy-like programmers.

Kindly explain the downvotes? I have nothing against Java. But C++ has direct control over memory and/or memory allocators, the option of allocating things on the stack, no garbage collection, etc.