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

Pages: 1-

What's the fastest language?

Name: Micheal 2010-05-16 6:03

(Bar Assembly) I know C++ is fast but definatly not the fastest. Would it be LISP? or am i thinking that just because it's an old language..

Name: Anonymous 2010-05-16 6:06

C is the most abstraction-free and portable language you can find

Name: Anonymous 2010-05-16 6:08

Debian shoutout, nigga.

Name: Anonymous 2010-05-16 6:14

Name: Anonymous 2010-05-16 6:20

>>1
definatly
( ≖‿≖)

Name: Anonymous 2010-05-16 6:21

( ≖‿≖)
oh look who's back

Name: Anonymous 2010-05-16 6:28

>>4

They do source-code-size comparison and yet they could shrink their Java by using conditionals and nonrepeating variables in some places...

Name: Anonymous 2010-05-16 6:34

>>1
Lisp is usually slower than C, but it can be as fast as C if you push it enough. Usually most people that use Lisp tend to just write everything as expressive/readable as possible, which can make things slow, then they optimize the parts that are too slow. Of course, Lisp offers a wide variety of optimization strategies, some of which are not offered by other languages (full control over compile-time calculations for one, caching and various code generation/manipulation tricks are also very easy to do). Lisp can be as fast or as slow as you want it to be, providing you have a decent implementation.

If you want speed, I'd say go for ASM and C. Lisp is a good choice too, but it won't be fast by default, it's usually slow because it lets you do whatever you want without questions asked, so you have to work to achieve speed, but its advantage is that it makes hard things simple, and it gives you a lot of flexibility on how you rewrite/redesign your code (usually with very little effort required), so you can test many algos easily. If you have a O(logn) algo in your Lisp program, and a O(n*n) algo in you C program, the Lisp program would be faster because of better choice of code, which tends to be easier to do in Lisp (altough, such choices are language independent, I usually end up writing a lot more code in C than in CL, so I find rewriting code much easier in CL). As for taking the same algo you wrote in Lisp and porting it to C, you'll only get linear performance gains from that if lucky, but sometimes it may be worth it if the CL implementation isn't good enough (it usually is just fine, but if you're writing C/Fortran in CL, you might as well just do it in C/Fortran).

Name: >>8 2010-05-16 6:36

It also has good natively compiled implementations, which can give it speed comparable with C (if enough declrations are used, otherwise, with all the runtime typechecks, maybe 1.5-3 times slower on average, which is acceptable if you compare it  with Java/C#, and hard to compare it with Python/Ruby or other languages whose main implementation is interpreted (altough the problem there lies in the current implementation, and less in the language)).

Name: Anonymous 2010-05-16 6:51

>>6
BACK MY ANUS

Name: Anonymous 2010-05-16 8:05

What about COBOL?

Name: Anonymous 2010-05-16 8:37

FORTRAN mutha fucka's!

Name: Anonymous 2010-05-16 9:13

turbo pascal

Name: Anonymous 2010-05-16 11:16

>>13
Enjoy your non-optimizing compiler.

Name: Anonymous 2010-05-16 13:04

>>14
enjoy my non-optimizing ANUS

Name: Anonymous 2010-05-16 14:05

>>15
enjoy my ANUS

OTFY

Name: Anonymous 2010-05-16 18:08

white space

Name: Anonymous 2010-05-16 18:28

>>11
There's no inherent reason COBOL should be any slower than Sepples (and only a few why it should be slower than C), but COBOL compilers aren't exactly state-of-the-art nowadays. They'll always end up near the bottom of meaningless comparisons like this.
Still faster than Ruby, though.

Name: Anonymous 2010-05-16 19:23

[sup]A[sup]I[sup]D[sup]S[sub]I[sub]N[sup]M[sup]YANUS[/sup][/sup][/sup][/sup][/sup][/sup][/sub][/sub]

Name: Anonymous 2010-05-16 19:31

>>19
How does this happen, anyway? There are so many bbcode implementations out there, and you couldn't figure out how to use a single one to validate your code?

Name: Anonymous 2010-05-16 19:36

>>20
Why are you expecting intelligence from an HMA spammer?

Name: Anonymous 2010-05-16 19:49

EXPECT MY ANUS

Name: Anonymous 2010-05-18 16:02

Name: Anonymous 2010-05-18 16:23

>>23
SHOOT OUT MY ANUS

Name: Anonymous 2010-05-18 16:25

>>23
the haskell programs had to be made inefficient because butthurt java programmers kept whining about ghc being lazy.

Name: Anonymous 2010-05-18 17:09

>>23
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=java

A much more interesting benchmark. GHC-compiled programs are almost always on par with Java, except for fannkuch and k-nucleotide, which are vastly slower than their Java counterparts. Also, almost all of the GHC programs use much less memory.

Name: Anonymous 2010-05-18 18:03

The shootout has always been more of a benchmark of the programming skill of the algorithm implementors than of the speed of the language implementations.

Name: Anonymous 2010-05-18 18:58

>>26
Funny how, when confronted with failure, Haskell users will change the rules.

Just like how the ghc programmers will modify the code for performance only to achieve better benchmarks, rather than striving for actual improvement.

Name: Anonymous 2010-05-18 19:46

CONFRONT MY ANUS

Name: Anonymous 2010-05-18 20:03

>>28
If you optimize for enough benchmarks some time down the road real applications will run faster too.

Name: Anonymous 2010-05-18 20:59

>>30
Oh I get it, the joke is that there are no real applications (crappy window managers don't count) programmed in Haskell.
Clever.

Name: Anonymous 2010-05-18 22:05

>>31
txtsushi is a fine application

Name: Anonymous 2010-05-19 3:30

>>23,26
I've always wanted to see Asm on that chart.

Name: Anonymous 2010-05-19 3:44

Python of course.

Name: Anonymous 2010-05-19 11:44

>>33
I've always wanted to see compiler on that chart.

Name: Anonymous 2010-05-19 13:11

>>35
I've always wanted to see linker scripts on that chart.

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