[gameprogrammer] Re: RES: Re: C# vs C++
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Mon, 23 Feb 2009 16:33:46 -0600
On Sat, Feb 21, 2009 at 6:45 PM, Garrett Gaston <garrett85@xxxxxxxxxxx> wrote:
> I am a very VERY novice programmer, what do you mean when you call certain
> programming languages slow and fast?
When they say that a language is fast or slow they are saying that
code produced with that language takes less time or more time to run.
So, generally C code runs faster than Java code. But, the actual speed
of code execution is only somewhat related to the language.
No matter how fast or slow the language, a call to a function compiled
(or assembled) to the processors native machine language will take the
same amount of time to run. So, the actual "speed" of a language is
dependent on the percentage of code that is executed in machine
language and the percentage of code that is built in the programming
language in question. That means that an program that depends heavily
on precompiled code will run fast no matter the "speed" of the
language.
No language is either fast or slow. *Implementations* of a language
are fast or slow. C# and Java are traditionally implemented by
compiling them to what are called "virtual machines". That means they
are usually compiled to something that is not the native machine code
of a specific machine, but rather to some idealized machine. This
virtual code can be run on a specific machine in many different ways.
It can be interpreted, which is slow. Or, it can be recompiled to
native machine code (using what is called a JIT (Just In Time)
compiler) which can be as fast as native code because it is native
code. When a JIT compiler is used the implementation can appear to be
*very* slow for naive tests because the time need to compile the code
is included in the total run time of the test. Sophisticated tests
will show that the JIT compiled code is as fast as the compiled code
produced by any other compiler. Some virtual machine implementations
keep track of what part of the code is run the most and compile the
10% of code that takes up 90% of run time. These implementations can
appear even slower than JIT based system and yet give you actual run
times, for long running applications, that are as good as what you get
from languages like C/C++
Languages such as C/C++ are traditionally implemented by compiling
them to native machine code so you rarely find a "slow" implementation
of those languages. But, there have been implementations of C that
were interpreted and there are native machine language compilers for
Java. Not to mention that there are good and bad compilers. A really
bad compiler can generate very slow code.
Then there are languages that are traditionally implemented using an
interpreter. LISP and Scheme as well as the shell languages such as
Bash, are traditionally interpreted and are generally considered to be
"slow". OTOH, I have seen an used an optimizing LISP compiler that
generated numeric code that out performed the best FORTRAN compilers
available at the time.
So.... when someone says that a language is fast or slow they are
really talking about the performance of implementations of a language,
not the language. And, usually they are talking about the performance
of the dominant implementation or the implementation they are most
familiar with.
OTOH, there are languages with features that impose run time overhead
that you don't find in other languages. For example, languages that
include some type of automatic storage management by either garbage
collection or reference counting, must pay for the extra service
somehow. If the language does more it costs more at run time. So, the
language design can make it slower. But, if you are coding in C/C++
for speed and then turn around and add automatic storage management in
your own code you'll often find that your implementation slows your
code down as much, or more, as using a language with that feature
built in.
So, really, when some one says that language X is faster than language
Y they are not saying what most people think they are saying.
Bob Pendleton
>
>> From: dirso@xxxxxxxxxxxxxxxxxx
>> To: gameprogrammer@xxxxxxxxxxxxx
>> Subject: [gameprogrammer] RES: Re: C# vs C++
>> Date: Fri, 13 Feb 2009 10:10:33 -0200
>>
>> Last project I worked on I also had to make some improvements in some
>> applets - what a nightmare!!! - As the manager said told me once: "Did you
>> ever see a Flash application loading the plugin? Why does java need to
>> initialize every time?". Anyway, I didn't have this problem with the
>> DirectX
>> application developed in C#.
>> Nice joke ;)
>>
>> -----Mensagem original-----
>> De: gameprogrammer-bounce@xxxxxxxxxxxxx
>> [mailto:gameprogrammer-bounce@xxxxxxxxxxxxx] Em nome de Chris Nystrom
>> Enviada em: quarta-feira, 11 de fevereiro de 2009 17:25
>> Para: gameprogrammer@xxxxxxxxxxxxx
>> Assunto: [gameprogrammer] Re: C# vs C++
>>
>> On Tue, Feb 10, 2009 at 5:07 PM, Matthew Weigel <unique@xxxxxxxxxxx>
>> wrote:
>> >
>> > Yep, C# and Java have entered the realm of "fast enough for a lot of
>> things"
>>
>> Joke:
>>
>> Knock Knock...
>>
>> Who is there?
>>
>> (wait)
>>
>> (wait)
>>
>> (wait)
>>
>> Java!
>>
>> Chris
>>
>> --
>> E-Mail: Chris Nystrom <cnystrom@xxxxxxxxx> Saving the world from web
>> programming.
>> http://www.newio.org - G-Talk: cnystrom
>>
>> ---------------------
>> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>>
>>
>>
>>
>> ---------------------
>> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>>
>>
>
> ________________________________
> Access your email online and on the go with Windows Live Hotmail. Sign up
> today.
--
+ Bob Pendleton: writer and programmer
+ email: Bob@xxxxxxxxxxxxx
+ web: www.GameProgrammer.com
+ www.Wise2Food.com
+--------------------------------------+
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts: