Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

I totally did not expect this!

Name: Anonymous 2011-08-06 6:59

http://shootout.alioth.debian.org/u64/which-programming-languages-are-fastest.php?calc=chart&gcc=on&gpp=on&javasteady=on&ghc=on&ifc=on&sbcl=on&vw=on&python3=on

GCC and G++ are the fastest. That's the norm.
Java7 faster than Haskell and Fortran. WTF?
LispSBCL and SmalltalkVW faster than Python 3. Jesus Christ.

Name: Anonymous 2011-08-06 7:05

Ada is faster than C++, VROOM VROOM.

Name: Anonymous 2011-08-06 7:05

Java7's JIT compiler optimizes so much it corrupts the code. Don't use it.
Also, Common Lisp's implementations are generally rather fast and Python's are generally terribly slow.

Name: Anonymous 2011-08-06 7:40

What's really surprising to me is that Java is roughly as fast as C++. Sometimes only twice as slow, and sometimes even faster. Really good job for a much higher level language?

Name: Anonymous 2011-08-06 7:41

>>1
Python has and always will be terribly slow. Lua and Ruby are in the same boat.

I don't know why so many novices think Python is fast when it clearly is not.

Name: Anonymous 2011-08-06 7:48

inb4 Java programmers talk about how they are better than FORTRAN and Haskell programmers when it takes much more skill to get optimise Java than it does those.

Name: Anonymous 2011-08-06 7:56

>>4
Don't get so high on yourself just yet. MSVC++ produces code that is roughly 15-25% faster than GCC/G++. Intel C++ produces code that is roughly 20-35% faster than GCC/G++. Clang/LLVM is around on par with GCC but could overtake it in the optimization department due to its faster development pace.

Instead, all this experiment does is pit one compiler against another. While language constructs and libraries ultimately do have an impact and limit resulting program performance, the quality of the compiler is also just as important.

GCC is a horrible compiler full of hacks and legacy that is developed at a glacial pace.

I would like to see the open-source Intel C++ compiler added to these benchmarks, and perhaps Clang/LLVM as well.

Name: Anonymous 2011-08-06 7:59

>>1
The advantage the bit-twiddling languages like C, C++, and now Go, provide is the ability for the programmer to apply optimizations by hand. This is an advantage to a language designer- all that tedious optimization work can be skipped (notice how proud the Go designers are of compile time- optimizations take time for the compiler to apply). Hand applying optimizations is also an advantage in micro-benchmarks (like the Shootout), and in blog posts and similar. Places where the code size is small enough that the cost, especially in terms of lost abstraction, is negligible.

The problem is that we’re not writing blog posts or micro-benchmarks. We’re writing whole systems. Programs of non-trivial complexity, tens or hundreds of lines of code, possibly even millions. Programs too large for us mere mortals to hold in our heads- at this point abstraction and simplicity are not options, not things that are not nice things to have that we can no longer do without. They are absolute necessities. When our programs are at or near the limits of our comprehension is when the extra complexity of hand optimization can be least afforded- large scale systems programming is the last area that should be doing hand optimization.

Name: Anonymous 2011-08-06 8:04

>>7
The comparison with Intel compiler and MSVC is not valid. First is not free, second is both not free and not cross-platform. OpenJDK is free and cross-platform.

Name: Anonymous 2011-08-06 8:08

>>9
They aren't using the OpenJDK in the benchmarks to test Java, they're using Oracle's proprietary Java 7 and Java 7 Server JVM implementations, so your point is invalid.

Name: Anonymous 2011-08-06 8:10

>>8
Instead of applying the optimization one time for everything so that not only that specific part of your code, but all the code that passes through that optimizer, you choose to apply it to only one, specific part of your code to make it run fast, only in one place, only for that code, bloating your code with unreadable, impenetrable, ``I don't even know what I meant here one month ago'', unidiomatic hacks that may and will increase the complexity of the code both for the optimizer to apply new, better optimization, and for humans to read?

Name: Anonymous 2011-08-06 8:14

>>8
I've never had problems adapting and comprehending million+ lines of code projects. After a month or so of getting acquainted by performing small refactoring across the code base, I'm ready to make large changes. I've built such behemoths myself and I've been able to comprehend them in their entirety. I guess that's just one of the benefits of being mildly autistic.

Name: Anonymous 2011-08-06 8:16

>>8
Have you ever heard of the term "abstractions" within the context of systems architecture? You don't need necessarily need to comprehend an entire system to perform hand optimization, you only need to understand the scope and limitations of the subsystem you're optimizing.

Name: Anonymous 2011-08-06 8:17

>>10
Weren't they open source?

Name: Anonymous 2011-08-06 8:22

>>14
Only parts of it and it's released under a restrictive non-free license that does not permit distributing source copies or source modifications. Most of the Java 7 Server stuff is entirely closed-source.

Name: Anonymous 2011-08-06 8:41

>>4
The great thing about abstract, higher-level languages happens when one programmer writes abstract logic; the compiler can do more work optimising the code. The thing about lower level languages is that the programmer must expend a lot of effort to control the compiler to get it to write optimal code.

Name: Anonymous 2011-08-06 9:29

>>16
the compiler can do more work optimising the code.
That's the hope, but the reality of the situation is that the compiler authors for newer or less-popular languages often give up halfway once they get to the point where making further changes breaks ABI backwards compatibility, when it becomes too difficult to maintain the code base, or when it has become good enough for their personal needs or maintaining their user base.

This is in part also due to the fact that unless your language becomes as popular as C, C++, Java, etc. with many multiple implementations of compiler tool chains, there's no competition among vendors to deliver better tools. That's largely why C and C++ enjoy their performance crowns... competition between compiler authors/vendors over the decades has born ripe fruit.

Name: Anonymous 2011-08-06 9:58

What the fuck is ATS?

Name: Anonymous 2011-08-06 10:07

>>17
That's why new languages choose to target JVM or .NET now. Clojure is a very recent language but still has a much better performance than Python for instance. It works.

Name: Anonymous 2011-08-06 10:22

>>19
Or LLVM. I wish more languages would choose LLVM over JVM/.NET. LLVM isn't burdened with a GC, lack of unsigned types and lack of SIMD vector types. It has much more potential for future performance enhancements.

Name: Anonymous 2011-08-06 10:24

ooc.lang.llvm

Name: Anonymous 2011-08-06 10:37

>>20
LLVM isn't burdened with a GC
I don't consider it a burden, it's a necessity. Can you imagine a Lisp without a GC? This also true for all high level languages. You think it would be a good idea for them all to invent their own GC? That's exactly what they try to avoid by targeting an existing virtual machine.

Name: Anonymous 2011-08-06 11:20

Assembly languages are not burdened by GC

Name: Anonymous 2011-08-06 11:38

>>23
Unless they are.

Name: Anonymous 2011-08-06 11:41

>>24
Yes but that is not the point.

Name: Anonymous 2011-08-06 13:15

>>18

"ATS is a programming language that unifies specification and implementation. Within ATS, there are two sublanguages: one for specification and the other for implementation, and there is also a theorem-proving subsystem for verifying whether an implementation indeed implements what is specified"

http://www.ats-lang.org/DOCUMENTATION/proginats/HTML/book1.html

Name: Anonymous 2011-08-06 13:26

>>5
Lua 5.1.4 != LuaJIT
http://luajit.org/performance_x86.html

Python 3.2.1 != PyPy
http://speed.pypy.org/

Name: Anonymous 2011-08-06 13:27

>>26
What a disgusting language.

Name: Anonymous 2011-08-06 14:14

SBCL wouldn't suck if it didn't produce 50 megabyte binaries.

Name: Anonymous 2011-08-06 16:01

>>29
It churns out fasls in the kilobytes.

Name: Anonymous 2011-08-06 16:30

Name: Anonymous 2011-08-06 16:33

>>1
"Java7 faster than Haskell and Fortran. WTF?"

For some programs, not for all programs.
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=ifc&lang2=java

Name: Anonymous 2011-08-06 17:12

Java7 faster than Haskell and Fortran. WTF?

I hate all these stupid speed benchmarks that pay no attention to memory usage at all. Of course you can unroll the fuck out of all the loops and pad liberally with 64-byte alignment but then you're making a huge sacrifice in size. They should use efficiency metrics like speed/size to compare.

99% of code does not need to be optimized for speed, and should be optimized for size instead.

Name: Anonymous 2011-08-06 17:18

>>33
640K ought to be enough for anybody.

Name: Anonymous 2011-08-06 18:12

>>33
As memory usage is reported, I guess you just haven't looked.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List