>Java and JavaScript are slow Literally faster than C and C++

wtf i love india now!!!

>>57684724
>faster
JavaScript and C/C++ are equal in that though. It's just Java which is faster. No surprise though. The only languages that have any chances at competing with high-level Java are hilariously young. (Golang, for example, which has hilariously bad GC.)

No question that C is a horribly shit language though. Can I get a citation for that image, so that I might check what the score is for Fortran and Ocaml?

>>57684881
sure
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/

That doesn't make sense, how can a language running in a VM environment be faster than a native one?

That's complete bullshit

>>57684984
>>57684962
c-cucks btfo

>>57684962
Maybe C was compiled with no optimization and java optimized the empty loop away?
Or maybe they run malloc million times...

>>57684724
>Python 3

I hurt myself today

>>57684962
the JVM analyzes it at run-time and produces (close to) optimal code based on the real-world performance in the real-world circumstances.

normal compilers for C/C++ can only make a best guess and they have to make deliberate compromises since it will run on different machines (unless you use -march=native, but even then it's not perfect)

>>57684984
It's a test that doesn't prove anything except bias from the test maker. After 2008 or something JVM got runtime optimizations. It means it will optimize away while 1 loops that do nothing and keep code it executes often readily available for execution. If anything it shows that the person writing the C and C++ tests aren't a good programmer.

>>57684962
>>57685013
compiler loop unrolling

If the number of iterations wasn't known at compile time, or optimizations were turned on, then C would probably win

>>57685039
>tfw Google sells it as they made this in the android

>>57685039
also java really shines for long-running applications like servers because of the run-time optimizations and also the garbage collector which basically ensures there is no memory fragmentation. C/C++ typically have very shitty hand-coded memory management and they will slow down after a while so that you have to restart the program for it to run fast again.

>>57685076
>they will slow down after a while
maybe

>>57685099
not always, it depends on the program. programs that have malloc/free or new/delete everywhere tend to be bad at this

>>57685073
but java isn't compiled!

File: 1415897211302.png (129KB, 625x626px) Image search: [Google]

129KB, 625x626px

>>57685039
>>57685076
>>57685110
You have no idea what you're talking about Pajeet.

>>57685131
lol k keep thinking your programs are optimal just because you have a basic understanding of C syntax

>>57685131
>angry c cuck resorts to name calling after his language turns out to be worse AND slower!

>>57685114
https://en.wikipedia.org/wiki/Just-in-time_compilation

>>57685076
C++11 and C++14 fixed the "hand coded memory" management. And no a C or C++ program will not slow down as long the people writing the code aren't fucktards that do too many allocations instead of just allocating a larger chunk from the beginning.

And the way java handles memory is retarded. It keeps allocating memory until it runs out of memory. Then it pauses execution to run the gc.

>>57685148
>>57685160
How do you think your beloved garbage collector / java heap allocater is implemented?

>lol java is faster than native code and asm!
Why did I even take the bait?

>>57685114
What is javac?

>>57685110
>programs that have malloc/free or new/delete everywhere tend to be bad at this
What is your point? If you are right the coreutils should be eventually killed by OOMK. You literally fuck up your code with malloc to do this.

>>57685183
having a general-purpose allocator beats not having one at all, and even if you have a custom allocator and engineered everything perfectly yourself, not all applications need it and the higher productivity and easier accessibility of java can be more than worth the potential performance difference

>>57685218
>moving the goal posts

>>57685242
nope, i'm not saying C/C++ can't be fast, i'm just saying C/C++ programs can be suboptimal if the programmer doesn't know what he's doing

>>57685258
To add, it`s also almost impossible for a single developer to beat Java

File: CthyVVWWcAAIq-a.jpg (197KB, 914x1200px) Image search: [Google]

197KB, 914x1200px

>>57685291

How does it feel that we live in an age where the JVM is so efficient that performance (both execution time and memory use) is even COMPARABLE to native code.

Pajeet barely knows java and yet he can write better code than the fizzbuzzing, /g/-autists because of the nice people at Oracle handle all the compiler tweaking for him.

>java 40% faster than asm

I hope whoever made this (((benchmark))) lost their job. Luckily for them the only thing more incompetent than Pajeet the coder is Rajeesh the manager of the Pajeet unit.

>>57685258
I actually enjoy programming in C++ and I find it easy. As long you stick to sane practises so you don't do retarded shit. The current drawback of C++ is header files, incomprehensible template compiler errors and that you need a third party libs for stuff that's included in other languages standard library.

>>57685291
I find that hard to believe. Pajeet coder probably yes. If you were right everything would be written in Java. Even video encoders.

File: 1465212873116.png (10KB, 478x373px) Image search: [Google]

10KB, 478x373px

>>57684724
>Java is faster than Assembly

>>57685395
>>57685352
hey, NEETs, you can view the code itself: >>57684906

>>57685395
>java generated assembly is better than pajeet generated assembly

really makes u think...

File: e94.jpg (27KB, 310x394px) Image search: [Google]

27KB, 310x394px

>>57685424
>still implying Java is faster than Assembly

>>57685468
you're welcome to write better assembly yourself

>>57685468
java is assembly in the end

>>57685486
topkek

>>57685489
nope, literary the oposite

>>57685498
what even is the opposite of assembly?
basically Java writes better assembly than humans at this point, accept it

File: cheetah's_thoughts_on_your_post.jpg (81KB, 500x334px) Image search: [Google]

81KB, 500x334px

>>57685218
>easier accessibility of java

>>57685445
kek

>>57685505
Java is a virtual machine with the point of being multi architecture compatible
Assembly is the direct opposite, being direct hardware and very specific

>>57685424
>// This is another trick to avoid compiler's optimization.
No wonder Java is faster. They turned off all compiler optimizations for C++ and wrote inefficient C++ code on purpose. A fair comparison would have been to use a JVM with all kinds of optimizations turned off. But the point of that blog post was not to have a fair comparison of languages and their compilers. It was to "prove" java is the best.

>>57685593
can you actually disable java's optimization?

File: 1479254347726.gif (3MB, 355x201px) Image search: [Google]

3MB, 355x201px

>>57685486
>implying no one can program better than Pajeet

>>57685498
>nope, literary the oposite
I think he means processor op codes. If you try to claim java doesn't translate your byte code to processor op codes you need to stop posting.

>>57685593
you're misunderstanding. they're simply printing the variable at the end so the compiler doesn't remove everything altogether

File: 1473032827959-2.png (171KB, 374x347px) Image search: [Google]

171KB, 374x347px

What the literal fuck with these java shills on /g/?

well pack it up everybody this blog post done seal the deal

>cherry picked benchmark
>nested loops
>nothing to indicate what runs inside the loops
>nothing to indicate compile options

poor quality bait

>>57684724
>assembly is slower than C
wtf?

There has to be a way for any language, regardless of whether its compiled or scripted, to be able to boil down to machine code. How is it possible that a language that is abstracted, has faster run times than one that 1 to 1?

Whoever wrote all of the code sucks at it

>>57685604
You can completely turn off jit with the Xint option

>>57685649
poorly written assembly

>>57685635
actually i am a javascript shill

but the real question is the c shills - literally 0 fucking benefit

>>57685649
see >>57685486

>>57685649
isn't assembly the same speed as C
10=10

So someone benchmarked 3 for loops? Are u kidding me? Please stop breathing

>>57685604
I don't know but it was clearly not in the interest of the blog author to do that in the first place. These kind of "java is faster than C++" benchmarks have been showing up for almost a decade now. Yet we don't see video encoders written in Java.

>>57685631
They turned off optimizing when compiling the C++ code. Yet they allow the JVM to analyze and optimize the code at runtime. Hardly a fair benchmark. Plus the C++ code do queries for time while the java implementation does not.

>>57685733
>They turned off optimizing when compiling the C++ code.
where does it say that? they print the value in both C++ and java, because removing the code altogether would be a valid optimization if the value isn't being used

>>57685863
Read the comments to the post

>one guy has 1ms execution time code sample for C++

>other guy says example is misleading due to not printing all loop variables because java optimizes away the outer loops
>says that printing all loop variables in Java will make execution time for Java 17s while the C++ sample printing all loop variables will execute in half time using -march=native and -O3

So Java confirmed for being twice as slow as C++. But Java sure is great if you are a shitty coder.

>>57685929
So does that still mean that C (not ++) is still slow as fuck?

>>57685929
the 1 ms sample is not equivalent. the compiler probably infers the end result without doing any computation at all.

printing all loop variables is not something you would do in a real-world application and it would measure console I/O rather than the loop logic.

>incrementing a counter is a good benchmark
The JIT probably just converted the code to a single line
x = 1000000

>>57685948
No

>>57685975
He "cheated" and used the full power of his CPU by using OpenMP. Not sure O2 optimizes away the loops. At best it should do similar optimizations as the JVM.

>>57684724
>gettimeofday() in benchmark, instead of clock()
Good job, idiot. Now the scheduler has a role in your benchmark.

>>57686028
ok after reading thru the comments it looks like the JIT or java or whatever gets rid of unnecessary outer loops. so the author purposefully wrote the benchmark so that java would do the best.

In useful programs this would basically have no impact

>>57686140
This is the case for every Java is faster benchmark that has been made the past decade. There is a reason why these benchmarks never get traction outside their little circlejerk.

>>57685424
>turning java byte code in to assembly and running it is 40% faster than running assembly
>assembly is 40% faster than assembly

>>57685948
It's just nested loops right? There's probably no difference in the C and C++ implementation. I see no reason to go in to anything c++ specific.

>>57686140
>Optimizing compilers optimize
wow much insight.

>>57686075
openmp has nothing to do with it. you don't go from seconds to milliseconds just because you use a few more cpu cores. the code is not really equivalent, it uses modulus instead of the if statement and the compiler infers the end result through arithmetic, not by running any significant amount of code at run time

>>57686172
when people talk about assembly they mean handwritten assembly. you must have a severe case of dunning-kruger if you think you can write consistently faster handwritten assembly than the compiler

kek the C code doesn't even compile.

>>57686641
did you know compilers are written by humans

>>57686751
Did you know calculators are designed by humans? That means there's no possible way a calculator can be faster than a human in peforming computations.

>>57686765
yeah theres no way a human does the thousand something loops faster than a computer either but we are talking about writing the code not doing the operations yourself

>>57686641
This is a nested loop not a 100k loc team project. Looks like you're projecting. Meanwhile you're defending a guy who didn't even run his shit through a compiler to see if it is valid code.

>>57684724
>muh handcherrypicked, numeric benchmark

>>57684724
>posts a year old image from some taco nigger's site with no explanation as if it supposed to mean something
Literally retarded

>>57686826
k

>>57686792
Isn't writing code just performing a bunch of operations?

>>57684724
The only people who still think Java is slow are /v/-tier kiddies with outdated second hand information.

>>57687017
programming is designing an algorithm to solve a problem using a computer
coding is implementing the algorithm
it's not doing 1+2, it's telling the computer he has to do 1+2

"Why are people still using bloated and slow python, perl is the hacker language and is even faster then that crappy python" ~if I had to believe the graph

>>57684962
It isn't, but Java can come very close. This is assuming you even are using a VM, because Java in an of itself is just a language, and it can be compiled to a native executable, but it's not commonly used like that as one of the main advantages of Java is it being cross platform.

These results, just like many statistics on the Internet, are not 100% accurate. Whoever made the tests probably didn't know what the fuck they were doing.

>>57684724
tested this myself:
c++ 23.5 sec
java 12 sec

after adding -O2 compiler option, c++ program executed in 13.6 sec

Maybe c++ performed 1.6 sec slower because this case is very specific. In real programs you won't see such results. Also if garbage collector slowdowns are counted, java is much slower than c++

>>57685173
>And no a C or C++ program will not slow down as long the people writing the code aren't fucktards
sum up of all the bullshit in this thread

Pythonfags rightfully on suicide watch

This is Apple’s special tool to help customers recover data from the MacBook Pro’s non-removable SSD
https://9to5mac.com/2016/11/24/apple-special-cdm-tool-macbook-pro-ssd-recover-repairs/

>>57688104
Now modify both programs to print all loop counters.

File: spurt.png (98KB, 600x500px) Image search: [Google]

98KB, 600x500px

>>57684724
>If I write a code in Assembler in 32 bit instead of 64 bit
Yeah he starts out well

>bad c code is slower than good java code

whoa!!!!!

>>57684962
JIT compilation can be faster than AOT compilation in handpicked benchmarks, because in theory the JIT compiler can get information for optimization (in reality this fails in non-trivial examples and gets eaten up by the limited time to optimize).
Also, a good JIT compiler emits CPU specific code, whereas AOT compiler can only emit CPU family specific code in praxis, because muh compatibility.

In reality this all leads to Java being almost as fast as C/C++ except for special benchmarks where it's faster.

But the general point is that muh VM doesn't matter.
>>57688243
this, to be sincere

>>57687297
The compiler isn't doing programming you retard it's doing compiling, which is a fairly mindless task that computers can do much better than meatbags.

>>57688396
idiot

File: lel.jpg (7KB, 195x195px) Image search: [Google]

7KB, 195x195px

>>57684724
>java faster than asm
this is what happens when you believe in the JAVA CAN BE FASTER THAN C++ meme. java is only popular because of corporate shills.

>Scheme 1
Beat that nerds

>>57685173
>the way java handles memory is retarded. It keeps allocating memory until it runs out of memory. Then it pauses execution to run the gc.
It's actually a pretty good idea. Allocations only require you to add the allocation size to the current page pointer and return a pointer to its original position. It reduces the cost of individual allocations significantly.

Obviously it makes Java totally unsuitable for anything that needs to be low latency though.

>>57685649
You have to be an expert on Assembly to write faster assembly than a C compiler. Go read Agner Fog's assembly optimization guide. Assembly optimization is crazy.

File: 1405259459270.jpg (24KB, 462x327px) Image search: [Google]

24KB, 462x327px

>>57684906
>using the loop instruction in asm in 2016
>using the inc instruction in asm in 2016, when not optimizing for size
Why even program assembly if you don't know what the fuck you're doing?

I decided to try some actual code out. The most basic possible prime factoring algorithm.

    long n = 858599509;
    while (n > 1) {
        for (long i = 2; ; i++) {
            if (n%i == 0) {
                printf("%lu\n", i);
                n /= i;
                break;
            }
        }
    }

gcc (O3): 7.493s
clang (O3): 7.353s
java: 8.853s
measured with the Linux time utility. Looking at the objdump output, gcc and clang basically produced the same code.

>>57691805
it's probably worth noting that if I add the obvious optimization to exit when you reach sqrt(n), it finished instantly.

Where is C#?

>>57692092
Still loading

>>57684881
>golang
kys you are your selves

>>57684724
This shit again... https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

Why oh why do Javafags lie and lie.

>>57684880
poo?

>>57692569
Daily reminder that the C++ code on OP's doesn't compile.

>>57692304
Kek

>>57689651
I did that and the Java implementation became twice as slow as the C++ one.