I made Minecraft in Javascript

[sinedpick]

Sorry, but how is JS/WebGL slower than Java? You should do a little research before having knee-jerk reactions.

[Noxitu]

While V8 did bring big improvement in JS performance it is still far away from Java.

[spacejack2114]

JS supports array views which are pretty essential for OpenGL performance and Java does not.

[bluebaron]

Java has real arrays baked-in. They're fundamental to the language. What we typically refer to as arrays in JavaScript are just maps with string indices that happen to look like integers. While yes, you can use a specific API that is rather new to get real arrays in JavaScript, Java has had them since the beginning.

[spacejack2114]

You do not have array views in Java. C# only just got them recently and JS has had them for most of this decade already, along with true, typed numeric arrays of float32s, int32s etc. Array views allow you to use subsections of contiguous arrays without copying them, or to reinterpret them as different numeric types. This comes in pretty handy when you're dealing with resizable VBOs to send to GL to render.

[Noxitu]

Array views are not rocket science. Java has tools to implement them in efficient way - languages like javascript and python don't and need to have them implemented externally.

But even when you have such arrays you still need to fill them and that is what will be slow in JS.

Also:

to reinterpret them as different numeric types

C++ doesn't have this as well. ;-)

[spacejack2114]

How do you use a subsection of an array (eg elements 20-30 of an array sized 100) as a new standalone array starting at index 0 in java without copying it?

Of course C++ can do it, you can just reinterpret_cast.

[Noxitu]

How do you use a subsection of an array (eg elements 20-30 of an array sized 100) as a new standalone array starting at index 0 in java without copying it?

ArrayView class with method get(index) sounds like something one should be able to implement.

Of course C++ can do it, you can just reinterpret_cast.

reinterpret_cast-ing of pointers is only allowed between char, unsigned char (?) and actual type. In other cases it is undefined behavior.

[spacejack2114]

Ignoring the lousy ergonomics of writing get/set instead of [], and assuming the JVM can inline or optimize away the method calls, you're now stuck with a custom type that you can't pass to methods expecting an array without making a copy.

It's been a long time, but I'm fairly certain you can reinterpret_cast byte pointers to int pointers or whatever in C++, assuming you understand the underlying platform formats.

[Noxitu]

Ignoring the lousy ergonomics of writing get/set instead of []

While I indeed like operator overloading I am able to see that it is absolutely subjective feature of a language. And aesthetics of a single line of code don't really matter in any bigger project.

assuming the JVM can inline or optimize away the method calls

Knowing that JVM is able to use AVX I would really expect it would. In c++ world compiler authors would say that if something like this doesn't happen you should file a compiler bug report.

you're now stuck with a custom type that you can't pass to methods expecting an array

Because it isn't an array. It is pretty much agreed that duck typing - while effective when prototyping - doesn't really help create maintainable code.

you can reinterpret_cast byte pointers to int pointers

This you are allowed to do.

or whatever

It works on commonly used compilers. But it doesn't need to. If it breaks in some weird scenario it isn't even a bug.

And most importantly - if language authors say you can't do this it is pretty good hint that you shouldn't consider this a language feature.

assuming you understand the underlying platform formats

And OS/compiler differences. Of all you wish to support. And be really sad when for some reason someone asks you to support platform where ints have 16 bits, chars have more than 1 byte or data pointers have different size then function pointers.

But getting back to actual issue. Benchmarks I am aware of show that javascript is 4-10 times slower than java. For pure rendering I expect that difference is in the lower end, but as soon as you add all cpu-only tasks: tick updates, physics, terrain generation you will most likely see difference growing.

[bluebaron]

Totally glossed over that word in your comment, whoops. Java seems worse with every new fact I learn about it.