Best Programming Language for Jobs

[Yegg]

Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.

In computer programming class, a few days ago, I ran the following code side-by-side:

Java 1.4:

Code Select Expand

public class Main {
    public static void main(String args[]) {
        for(long i = 0; i > -1; i++) {
            System.out.println(i);
        }
    }
}

VC++ 6:

Code Select Expand

#include "stdafx.h"
int main() {
    for(long i = 0; i > -1; i++) {
        printf("%u", i);
    }
    return 0;
}

By the time Java reached 20,000, C++ was far past 60,000.

Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?

It's not accurate to do a speed test in that manner, and it's been discussed before.  Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.

I didn't want him to do the test  between C++ and Python to say that one was faster than the other, I knew that Python would be far behind C++. I'd just like to see the final result.

[Mephisto]

Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.

In computer programming class, a few days ago, I ran the following code side-by-side:

Java 1.4:

Code Select Expand

public class Main {
    public static void main(String args[]) {
        for(long i = 0; i > -1; i++) {
            System.out.println(i);
        }
    }
}

VC++ 6:

Code Select Expand

#include "stdafx.h"
int main() {
    for(long i = 0; i > -1; i++) {
        printf("%u", i);
    }
    return 0;
}

By the time Java reached 20,000, C++ was far past 60,000.

Hmm, quite interesting. I'm not sure how accurate such a speed test is, but could you compare Python with C++ in the same manner if you get the time?

It's not accurate to do a speed test in that manner, and it's been discussed before.  Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.

I didn't want him to do the test  between C++ and Python to say that one was faster than the other, I knew that Python would be far behind C++. I'd just like to see the final result.

And my reply had nothing to do with the nature of your complaint, so...

[iago]

Can a human even notice a difference in sped between Python and C++ for instance, no, they cannot in most cases.

In computer programming class, a few days ago, I ran the following code side-by-side:

Java 1.4:

Code Select Expand

public class Main {
    public static void main(String args[]) {
        for(long i = 0; i > -1; i++) {
            System.out.println(i);
        }
    }
}

VC++ 6:

Code Select Expand

#include "stdafx.h"
int main() {
    for(long i = 0; i > -1; i++) {
        printf("%u", i);
    }
    return 0;
}

By the time Java reached 20,000, C++ was far past 60,000.

The key words?

If it is optimized well while it is running, it is possible to skip large parts of processing that may or may not be required, then turn out to not be required. 

Try making the print conditional, if i < 0 print(). 

[iago]

Just for fun, I did the test.  Because Java has more startup time, I had to use significantly sized loops to prove the point.  Here are my programs:

Code Select Expand

int main(int argc, char *argv[])
{
    int i, j;

    for(i = 0; i < 10; i++)
    {
        for(j = 0; j < 100000000; j++)
        {
            if(i < 0)
                printf("%d\n", i);
        }
    }

    return 0;
}


Code Select Expand

public class Test
{
        public static void main(String []args)
        {
                int i, j;

                for(i = 0; i < 10; i++)
                {
                        for(j = 0; j < 100000000; j++)
                        {
                                if(i < 0)
                                        System.out.println(i);
                        }
                }
        }
}


Then I compile and run each of them:

iago@slayer:~/tmp$ make test
cc     test.c   -o test
iago@slayer:~/tmp$ javac Test.java


iago@slayer:~/tmp$ time ./test
real    0m5.531s
user    0m5.473s ***
sys     0m0.003s


iago@slayer:~/tmp$ time java Test
real    0m4.936s
user    0m4.832s ***
sys     0m0.010s

Does this prove that Java is faster?  No.  It proves that Java outperforms C in some situations. 

<edit> put astrisks beside the important value.

<edit2> for anybody who cares, if C is optimized:
iago@slayer:~/tmp$ gcc -o3 -o test test.c
iago@slayer:~/tmp$ time ./test

real    0m1.040s
user    0m1.020s
sys     0m0.000s

[Joe[x86]]

It's not accurate to do a speed test in that manner, and it's been discussed before.  Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.

It shows how fast it can do arithmatic, by incrementing a register.

And for anyone defending Java, I gave it the head start, because I couldn't do them both at once. I'd probably have been better off in the other lab, which has dual-cores (or dual-chip, I don't know), but you'll live.

[iago]

It's not accurate to do a speed test in that manner, and it's been discussed before.  Not to mention that something as insignificant as that (a few statements) is not indicative of speed of the language at runtime, IMO.

It shows how fast it can do arithmatic, by incrementing a register.

And for anyone defending Java, I gave it the head start, because I couldn't do them both at once. I'd probably have been better off in the other lab, which has dual-cores (or dual-chip, I don't know), but you'll live.

I suppose you didn't read my post where I used a system call to time a C and a Java version, and show that the Java one was faster?

And the slowest part of yours, by FAR, is the print.  I let it run for a few seconds, and pulled these stats:

Flat profile of 6.85 secs (608 total ticks): main

  Interpreted + native   Method                       
  0.2%     1  +     0    Test.main
  0.2%     1  +     0    Total interpreted

     Compiled + native   Method                       
  1.8%    11  +     0    java.nio.Buffer.<init>
  1.0%     6  +     0    sun.nio.cs.ISO_8859_1$Encoder.encodeArrayLoop
  0.3%     2  +     0    java.io.PrintStream.write
  0.3%     2  +     0    java.io.BufferedWriter.write
  0.3%     2  +     0    java.lang.String.indexOf
  0.2%     1  +     0    java.io.FileOutputStream.write
  0.2%     1  +     0    Test.main
  0.2%     1  +     0    java.lang.Long.stringSize
  0.2%     1  +     0    java.io.PrintStream.write
  0.2%     1  +     0    java.lang.Long.toString
  0.2%     1  +     0    sun.nio.cs.StreamEncoder$CharsetSE.implWrite
  0.2%     1  +     0    java.lang.Long.getChars
  4.9%    30  +     0    Total compiled

         Stub + native   Method                       
94.6%     0  +   575    java.io.FileOutputStream.writeBytes
94.6%     0  +   575    Total stub

As you can see, 95% of the time is spent writing out bytes, and only 0.2% is spent in your loop.  That's hardly a useful measure. 

Also, when you're running 2 programs simultaneously, they are sharing the CPU, which doesn't really make for a useful test.

[K]

Also I would bet that using System.out.println() forces the output buffer to be flushed to the screen. The C program using printf() will not flush the buffer after every call, probably resulting in a substantial performance gain. 

It would be interesting to try calling fflush() on stdout after every printf and see if the results change. 

[iago]

I believe at a newline character \n, the output is flushed. 

But you're right, the fairest thing to do would be to use cout, with endl's. 

But measuring output speed is pointless. 

[Yegg]

I believe at a newline character \n, the output is flushed. 

But you're right, the fairest thing to do would be to use cout, with endl's. 

But measuring output speed is pointless. 

What is the value of endl? Is it simply '\n'?

[Augural Sentinel]

What is the value of endl? Is it simply '\n'?

I found this with my Googling expertise:

Many programmers append the endl manipulator after each cout expression, as in:

Code Select Expand

cout << "user login" << endl;
cout << "enter your name: " << endl;
cin >> name; 

In the first line, the endl manipulator is added to force a line break. However, it's cheaper in terms of performance to use the '\n' character instead of endl because endl also flushes the stream rather than just adding a line break. Flushing a stream can be a costly operation. The second cout expression too has a redundant endl manipulator because the display must appear on the screen before the cin expression is executed, as cin and cout are tied.

The bottom line: avoid using the endl manipulator if you can because it slows down your program.

I've never heard this before and I've heard that endl is better.  Anyone else know which is "better"?

[K]

I always use std::endl instead of a \n.  Unless you're outputting to the screen rapidly -- and I mean very rapidly -- I doubt you will notice any performance difference in your program.  std::endl is also guaranteed to actually end a line on every platform, whereas windows likes "\r\n", *nix likes '\n' and Mac likes '\r'.

[iago]

endl flushes the buffers in addition to adding an endline character, similar to the way Java's System.out.println() does.  And yes, in this example, 95% of the CPU time is spent putting output on the screen, so that is the controlling factor.  Of course, it's a bad example in the first place, and it's already been explained why.

[Warrior]

You soo rigged that test iago.

[iago]

How?

And who cares?  The two programs do the same thing, and Java was faster.  Regardless of whether it was a contrived test, it proves that C isn't ALWAYS faster, as people here would have you believe.

[MyndFyre]

How?

And who cares?  The two programs do the same thing, and Java was faster.  Regardless of whether it was a contrived test, it proves that C isn't ALWAYS faster, as people here would have you believe.

And sometimes execution speed isn't the primary concern.  Sometimes coding speed is paramount.