Re: method calls faster than a loop?

Oliver Wong wrote:

"tom fredriksen" <tom@xxxxxxxxxx> wrote in message

Thats where you are wrong, they are then not equally efficient at a machine code level or cpu level or whatever you want to call it.

When you start talking about machine code, you're no longer talking about just the programming language, but also the compiler and Virtual Machines (if applicable) as well. That was my main point.

Yes, you all ways have to take into consideration all that make up a language to make it able to run on a computer, so languages are therefor still not equally efficient. Any language has to compile/interpret to machine code to be able to run, thats where the runtime efficiency of the language is measured.


There isn't a one-to-one mapping between programs written in a specific language and operations performed by the CPU. More specifically, there's theoretically no reason why you couldn't write a compiler that takes C source code and emits Java bytecode, or which takes Java source code and emits native Win32/x86 executables.

Furthermore, if you take two different Java compilers, there's no guarantee you'll get the same bytecode from the same Java source code. If you take two differen JVMs, there's no guarantee that you'll get the same sequence of operations from the same bytecode.

In other words, it doesn't really make sense to say "Method calls are faster/slower than loops", unless you add a heck of a lot of qualifications to that statement (e.g. "on this particular compiler, with this particular JVM, on this particular CPU, with this much RAM, on this OS, and these were the background tasks that were running, and here's my swap disk configuration, and here's how long I've let the JVM 'warm up' to perform optimizations, and here are the flags I've passed in, etc.")

All of the three above statements are valid to a certain extent, but it still does not disprove my statement.

Argh.. It annoys me that a lot of people programming higher level abstraction languages, compared to C, don't realise that the language is less runtime efficient because of all the implications of higher level abstractions in the language, which are inherent. Java and other interpreted languages are good languages, and I love them as well, but that does not mean they do not have there problems and that they have their areas of use and disuse.

This is not nescessarily so. A program written in Java, when compared to a similar program written in C, may perform slower with one particular Compiler/JVM/OS/Architecture/Machine configuration, but may before better in a different one.


See above statement.

Again, I stress that this is not simply an issue of programming language, but the entire stack of language, compiler, virtual machine, OS, architecture, machine configuration.

Except that the OS, architecture and machine configuration for one single machine does not change between to language test as I did, so they are irrelevant. But between different hw architectures it does make a difference that is true. Thats not the case in my test and I dont have access to other architectures so I cant make that estimate right now, but if I did I would of course try it there as well to see.



And that is certainly not true, that is why operating systems are programmed in C.

I'm not sure this is "why" operating systems are programmed in C. I figure the reason has more to do with the relatively few number of Java-to-machine-code compilers compared to the relatively large number of C-to-machine-code compilers.

Of course if there was another language which could consistently show better performance than C with higher abstraction levels so that the OS could have more advanced features or less errors and security problems, then that would be the reason. Unfortunately it is not so.

I'm not sure I understand what you're saying here. Are you disputing my above claim, or just making an unrelated side remark, or what?


I am saying that is why os's are still programmed in C.

Yes, compilers have improved over time.

But that doesn't mean that programmers are now better at guessing where the bottleneck in their program lies.

I have never said that and I am still not disputing the essence of knuths statement.

.

Relevant Pages

  • Re: casts
    ... I don't revere Nash as a computer science genius or whatever. ... compiler in a later edition of Visual Basic, ... and your front end GUI in any language that makes ... I've worked in Java before. ...
    (comp.lang.c)
  • Re: casts
    ... and was asked to teach it to prospective computer science majors at ... compiler in a later edition of Visual Basic, ... and your front end GUI in any language that makes ... I've worked in Java before. ...
    (comp.lang.c)
  • Re: casts
    ... This is why most shit programmers refuse to learn languages including ... C Sharp and Java. ... compiler in a later edition of Visual Basic, ... language for processing data. ...
    (comp.lang.c)
  • Re: Cpp Considered Harmful
    ... >> I will observe that many Java IDEs do this rather successfully. ... > Look, if a tool author is willing to fully parse the underlying language, ... > compiler version. ... mentions a header file is in the C compatability appendix. ...
    (comp.lang.cpp)
  • Re: Why this overloading example works this way?
    ... The rules of the Java programming language state that method overloading ... You seem to want the compiler to engage in some kind of reasoning ...
    (comp.lang.java.programmer)
Loading