Google Developers Are Looking At Creating A New libc For LLVM

[kpedersen]

You know as well as the rest of us, that it's possible to write fast and slow code, no matter what language you choose.

I have never quite understood this statement. If you write *exactly* the same code in Java and C++, the C++ program would both start up faster and execute each instruction faster.

There is no possible way that a VM on-top of another language / platform could be faster than just using the original raw native language.

Not saying this is relevant for Rust vs C++ speed (because they are both native), I am just saying that this argument / statement is very flawed.

Rust is great for performance, not necessarily the best performance, but that's not and shouldn't be in majority of cases the number one priority for choosing a language.

To be fair, if you write C++ correctly in the same safe manner as Rust provides (i.e shared_ptr / weak_ptr in many places), you will possibly be looking at a similar performance between the two anyway. Very similar assembly will be generated. Full of safety checks! .

My one issue with rust is that there are less compilers available. C has literally hundreds, C++ has 10 decent ones, so it is much more flexible when porting to another platform.

[yoshi314]

This is good; the GPL is doing its job. Not only is it ensuring the freedoms of users and developers, it is putting non-ethical companies like Google at a disadvantage because they need to rewrite an entire libc! XD

What I am not sure about is if they actually need to avoid the GPL in their binaries; building and linking with glibc does not require the source to be disclosed. So possibly it is a technical / size issue?

Either way it is great to see big companies having to waste their time with things like this and letting the little guys catch up.

i wonder that too.

i guess people are worried it's too gnu. gcc's licensing into gpl-3 was a pretty heavy blow to some companies. all of a sudden, llvm got quite popular because of that.

personally, i prefer the extra diversity. perhaps it might make it easier to have llvm on alternative operating systems?

[discordian]

I have never quite understood this statement. If you write *exactly* the same code in Java and C++, the C++ program would both start up faster and execute each instruction faster.

There is no possible way that a VM on-top of another language / platform could be faster than just using the original raw native language.

Not saying this is relevant for Rust vs C++ speed (because they are both native), I am just saying that this argument / statement is very flawed.

If you write the "same code" (as literally as possible) in Java and C++, you are limiting your code to the common denominator. In C++ you can use the stack (for class instances), in Java you only have the heap. In C++ you can easily compose classes (so you ideally just allocate space once), in Java you have references (multiple allocs) or deep inheritance (vtable, hard to maintain).
I seen code thats "faster" with Java, simply because it allocates/free an instance repeatedly and Java does reuse the memory or does the garbage collection later (outside your measurement). Of course if you place the instance on the Stack in C++ the game is over.

The argument is flawed both ways anyway, theoretically assembler is the faster, as all lang's eventually end up in machine instructions. That doesn't mean most people would write faster code if they switch to assembler.
Whats true though is that C++ gives you alot more options than Java which forces you to the same overly generic methods for everything, Java is inherently restricted.

[Pajn]

If you write *exactly* the same code in Java and C++, the C++ program would both start up faster and execute each instruction faster.

Startup faster yes, execute faster, no not necessarily

There is no possible way that a VM on-top of another language / platform could be faster than just using the original raw native language.

Yes, it's very possible.

Different compilers focus and optimise different things. It is not only completely possible but also very common that compiler A generates faster machine code for a specific piece of code than compiler B, in some cases compiler A may very well be the JIT compiler of a high level language.

Higher level languages can usually provide more power in their features and may automatically choose to use CPU features that seemingly the same piece of code that say, C, does not.

It's simply not possible to say that a "native" language always is faster than a language that is run in a VM. Especially with a JIT. A JITed piece of Java or even JavaScript is no less native than compiled C++ code. The main difference is other things than the compiler, like runtime checks for things like types or boundary, or not having a VM.

Startup time is different of course as an AOT compiler has done a lot of work a JIT compiler will have to do at startup but if you focus on that (like is done with JavaScript) it is possible to remove a lot of the cost with things like efficient interpreters, tiered compilers and, of course, caching of previous JITed runs.

[kpedersen]

Higher level languages can usually provide more power in their features and may automatically choose to use CPU features that seemingly the same piece of code that say, C, does not.

I still don't quite agree, a JIT system cannot generate faster assembly than an up front compiled binary with the same optimisations.

Lets say a JIT is smart and unrolls a loop. The compiler is also able to do this.
Again, lets say a JIT is smart and can generate code utilising SIMD, a compiler is able to do this.

A compiler also has better knowledge of the program, rather than simply a reactionary mechanism like a JIT only doing small parts, it can do a full program optimization.

A similar result can be seen when you compile into object files and then link. i.e:

$ c++ -c a.cpp
$ c++ -c b.cpp
$ c++ *.o

If you instead compile everything in one command

$ c++ *.cpp

it will be marginally smaller or faster depending on optimization flags specified because it knows inter-dependencies of all the functions and structures rather than just a small subset (i.e per unit).

Not to mention platforms that cannot JIT i.e locked down shite like iOS or sandbox platforms like ASM.js/WASM. A VM language isn't going to fly. But anyway I am possibly taking this a bit too off topic.

[oleid]

I have never quite understood this statement. If you write *exactly* the same code in Java and C++, the C++ program would both start up faster and execute each instruction faster.

What I mean is the following. The choice of language doesn't guarantee fast code. A poor programmer will probably create poor and slow C++ code. And probably slow rust and C code.

[Pajn]

I still don't quite agree, a JIT system cannot generate faster assembly than an up front compiled binary with the same optimisations.

"With the same optimisations" is never true in reality though. There will always be something that is implemented in some compiler and not, or not as well in someone else (and possibly the reverse for something else).

Sure a JIT can not do full program optimisations, but that does not matter as a JIT can do full function graph optimisations for a very hot function. I believe JavaScriptCore (the VM in Safari) did this previously when they used LLVM as their highest tier JIT.

But that is more about tricks a JIT can use to the same point as an AOT comiler. A JIT does have some advantages over a AOT compiler in that it can know things in runtime that is not guarantee-able at compile time for an AOT. For example can it realise that a dynamic dispatch never is dynamic and compile that with a static dispatch, or even inline it. Usually with a check that the assumption is still true (and otherwise do a deoptimisation) but that is still faster than a dynamic dispatch. Sure, an AOT compiler can do this via monoization and some (most notably Rust) does it quite frequently, but a JIT have better information and can do it without increasing the binary size.

Talking specific about the compilers, a JIT does the same thing as AOT with better information but with less time. For a specific optimisation that extra time can be more crucial or it can be that extra information.

[oleid]

My one issue with rust is that there are less compilers available. C has literally hundreds, C++ has 10 decent ones, so it is much more flexible when porting to another platform.

That's sadly true. A GCC and a cranelift-based backend are in the works, so _hopefully_ this will resolve in future.

[Guest]

If you write the "same code" (as literally as possible) in Java and C++, you are limiting your code to the common denominator. In C++ you can use the stack (for class instances), in Java you only have the heap. In C++ you can easily compose classes (so you ideally just allocate space once), in Java you have references (multiple allocs) or deep inheritance (vtable, hard to maintain).
I seen code thats "faster" with Java, simply because it allocates/free an instance repeatedly and Java does reuse the memory or does the garbage collection later (outside your measurement). Of course if you place the instance on the Stack in C++ the game is over.

The argument is flawed both ways anyway, theoretically assembler is the faster, as all lang's eventually end up in machine instructions. That doesn't mean most people would write faster code if they switch to assembler.
Whats true though is that C++ gives you alot more options than Java which forces you to the same overly generic methods for everything, Java is inherently restricted.

??? You can easily compose classes in Java too, not sure what you're talking about.

Bad memory management by developers isn't Java's fault. If an object is immutable or doesn't change in value, don't keep creating it again and again then - that's just stupid in any programming language. I mean you can easily do

variable = new Class

and then

delete variable

in a loop in C++, and I can guarantee you that someone on this planet has done it.

[Guest]

I have never quite understood this statement. If you write *exactly* the same code in Java and C++, the C++ program would both start up faster and execute each instruction faster.

There is no possible way that a VM on-top of another language / platform could be faster than just using the original raw native language.

Not saying this is relevant for Rust vs C++ speed (because they are both native), I am just saying that this argument / statement is very flawed.



To be fair, if you write C++ correctly in the same safe manner as Rust provides (i.e shared_ptr / weak_ptr in many places), you will possibly be looking at a similar performance between the two anyway. Very similar assembly will be generated. Full of safety checks! .

My one issue with rust is that there are less compilers available. C has literally hundreds, C++ has 10 decent ones, so it is much more flexible when porting to another platform.

Well actually JIT compilers/assemblers can detect CPU features and use more advanced instructions like AVX, whereas when you compile C/C++ programs for generic x86 machine (let's say Core 2 and above) you can't by default include AVX instructions (unless of course you added code in each program to detect CPU features and use one code path over another).