I mean, give them the same job with same aproch(means exactly the same way to do it), then which one of the following is the best in speed?
Assembly | Visual Basic | VB.NET | C | C++ | C# | Delphi | Java
I think programming lanuage does not matter, only the complier matters...
but is that so??? or not????
And from what I know, people say Assembly has the best speed....
But can Assembly do GUI's???
Provided that the coding is perfect, I think that Assembly language would almost always be faster - especially with larger jobs.
Java doesn't really come in to play - in the field of development languages built for a specific platform. Java is mostly a web browser language.
I know that you'd be able to optimize the code better using Assembly.
It may not be relevant to your question, but some languages allow the inclusion of Assembly blocks of code - that the compiler uses and it doesn't build this code. Given that fact, you could use Assembly blocks within a Delphi program (for example) - overriding any bits that compile to inefficient machine language code.
Assembly language absolutely can do GUI's, but building all of the related units doesn't make much sense when a 4th generation language could be used.
but is complier that determen the speed of the a program when they use the same lanuage?
like a C++ program complied with tourbo C++ and Borland C++ the speed shouldn't be the same, right?
Assembly code is by far the fastest as it is a direct low-level language. However, by the time you've written a program in it you'll probably have missed a few ice ages.
assembly code is by far going to make the fastest running programs....thats why its so hard to learn...lol
in my experience the better codes are the hardest to learn...i just cant figure out assembly (see my post about my assembly compiler problem in this forum area). Once i do however its probably the most capable langauge out there.
although...thinking now, wouldnt one of the older languages like pascal be faster since its more basic?
Note that in the long run maintenance is more important than speed (unless you're google
|tebeka wrote: |
|Note that in the long run maintenance is more important than speed (unless you're google |
If you're google then your maintenance is still more important. Search algorithms get stupidly complex very quickly. If you're google you just buy better hardware to compensate.
As everyone said assembly would be the faster but you will have no GUIs as it is literally individual CPU operation codes. You won't even have typed variables.
After that things become debatable, because higher level languages are more efficient depending on what you want to do. I would have thought that Java and .Net languages have a slight overhead for their bytecode interpretation.
I would not think that .NET languages would be faster....from what iv heard the VB.NET are pretty iffy, simple, and less than spectacular for lack of better words...
i would think either java or C++ would be your next best bet if you want some sort of GUI to accompany your program...
Yes, assembly is the fastest of all.
Let's do a simple job, adding two numbers. Our assembly program will put the numbers in the processor's registers, then add one to the other using the processor built-in add command. It may also set the overflow flag, but the whole process takes only a few cycles.
Higher level languages use variables (store the numbers in memory), then they call their add function, which loads the numbers from the memory into the registers and uses the pocessor's add function, then read the result and set it as its return value, passing it to the main program, which then gets it. A lot more, isn't it? I didn't take into account that they also initialize a bunch of routines which are commonly used, but in our example they aren't.
Java does it even more complicated. The bytecode passes to the virtual machine what it wants, the virtual machine does it as described above, then passes it back to the java program.
So, this is it, in a nutshell. In the end every program does the same thing, but the higher the language level, the more stages it goes through.
In the end, nothing makes assembly inherently faster than a (machine-dependently compiled) high level language.
For a simple (useless, and very very hypothetical) task, like (let's pick C as a high level language):
|int x = 2;
int y = 3;
x += y;
... in assembly, you could write:
|MOV eax, 2
MOV edx, 3
ADD eax, edx
(and maybe even optimize that based on CPU architecture - it's a loooong time since I did anything in assembly, and penalties and counter-logic instruction usage changes constantly)
... and a high level language compiler (like in the C case) might theoretically turn it into a more lengthy (and time consuming) piece of code, storing the variables in memory etc. And yes, that would be slower.
But in reality, a compiler wouldn't do that. Most optimizing compilers, if they came across this bit of code, would use registers for the variables, if any registers were available, in just the same way as a human assembly programmer. The compiled machine code would be identical.
Actually, in the above hypothetical example (looked at in isolation), a compiler would produce faster code, since it would realize that the result of the operation is never used for anything, so it would throw out the entire operation completely.
That last semi-joking point is actually important, because it shows part of the reason why there's no real point in assembly for anything but very short, often-used operations:
As soon as you get to a larger program, an optimizing compiler is likely to have a much better overview than a human programmer when it comes to bits of code that are never used; the most efficient use of the available registers; etc. etc.
The .NET-languages and Java are a completely different ballgame since, yes, they're not compiled into machine-dependent code. After all, that's their main strength.
Anyway, some real answers:
2. Assembly isn't necessarily faster than a high level language, unless we're dealing with a highly skilled assembly programmer (whose skills are also completely up to date). And even then, as others have pointed out, the improvement in execution speed still means a loss of (much more important) maintenance speed.
3. Dealing with the exact same tasks, .NET is actually faster than Java in most (if not actually all) cases (last time I checked). This regardless of whether we're dealing with VB or C# (and probably other .NET languages). Doesn't make VB as nice a language as C#, though
4. Yes, you can do GUI's in assembly. But it's probably as far from efficient as you can get.
5. An older, "simpler" language/compiler wouldn't produce faster code, since it's not built for optimization for the newer CPU's.
C++ is the best choice, i believe, for speed and overall developement time (since ASM is not user friendly).
C++ has very good speed, and then you can find the choke-points and optimize them with inline ASM:
int cVar = 4;
Well if you are a beginner I would say, go for some easy C++ coding.
There are a lot of great books you can read about it.
C++ makes a lot of sence and it's easy to learn
int a = 1;
int b = a;
can you guess what b is?
You can also do almost anything you want with it, if you want a game server, game client, software for sms sending(if you have the hardware of course), ANYTHING!
I would also suggest you to read a few wikis and stuff, just search for C++, int, variables, pointers, anything!
Wiki has it all
|Mgccl wrote: |
|I mean, give them the same job with same aproch(means exactly the same way to do it) |
This sentence makes this topic irrelevant, since you aren't able to make the same job while using the same approach. If you build the same job in ASM, imperative language and OO language, it's impossible to have the "same approach".
|Kaneda wrote: |
|1. One high level language isn't faster than another. |
In theory, yes, but in practice, I think, code written in some languages is inherently easier to optimize than code written in some other languages. In a language that lacks structure, it may be impossible for the compiler to know that, say, a certain variable or bit of code will not be used, so it cannot strip out that code. There's also the fact that some languages just don't give you the possibility of doing certain things -- an extreme example would be a BASIC dialect that gave you no access to pointers.
When I first started programming (which was many years ago when computers were touchy beasts that required large rooms full of tape machines and flashing lights), the speed issue was absolutley critical and learning how the compiler optimised your code was essential. And speed could be influenced by a wide variety of issues, such has the underlying structure of a data item.
Back in those days, COBOL was the norm and provided a dizzy array of numeric data types. I remember a particular "problem" with the use of two numrics types in particular. The flavour of COBOL I was using at the time called these COMP-3 (essentially decimal digits stored in each half-byte) and COMP-6 (a binary integer stored in a single processor word - which was 36 bits longs for interesting but highly irrelevant reasons). Quite a number of the programmers I worked with were unaware if this difference and had habitually used COMP-3 whenever they wanted a counter, particularly a loop counter.
I looked at the generated compiler code for some common instructions (particular adding a constant - usually 1 - to these items) and found that a COMP-3 ADD required 3 machine words but a COMP-6 only required 1. I demonstrated that using the COMP-6 was up to 20% faster, especially when loops were nested. After my demonstration, someone asked "But why doesn't the compiler do it for us?".
The world now
Compilers will do wonderful things with your code and can, with good optimisation, produce machine code which surpasses all but the best human coders. The operating systems we use provide services which would have had to have been developed from scratch back then. The majority of these services weren't written in Assembly Code: they were written in a high-level language. Our programs today rely more and more on using these services to produce the required result; they save us from re-inventing the wheel.
The question about "which language is fastest" is rather nonsensical since the majority of our programming efforts depend so heavily on other people's code (even if we write in Assembly Language).
Back in the 1980's when no personal computing magazine was complete without its benchmark listings, one of the most common benchmark tests for computers/languages was using the Sieve of Eratosthenes to find ever higher prime numbers. One enterprising producer embedded this algorithm in the BASIC interpreter and added a SIEVE statement to the language so that their interpreter could be the fastest at this benchmark. "Fastest language" is a very convoluted subject.