[gameprogrammer] Re: C#
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Mon, 13 Dec 2010 20:21:29 -0600
On Mon, Dec 13, 2010 at 3:36 AM, Dheeraj Patni <dheeraj.patni@xxxxxxxxx> wrote:
> hi,I am a c++ game developer..I like C++(actually love it ) and i like game
> programming...
> but i see some of the threads like c# is faster than c++ in JIT enviornment
> (i even dont know what is JIT???) because it uses cache..and smthing like it
> bla bla bla....
JIT stands for Just In Time. Java is *usually* compiled to a the
machine language of the Java Machine. You can build a Java Machine in
hardware and it will run very fast, as fast as native machine code on
any kind of machine. But, even though several hardware implementations
of the JM exist, we don't have them on our desktops or in our game
consoles. So.... We can either write an interpreter (also called a
Virtual Machine) that interprets JM code on the machines we do have.
Ok, that means that you have to execute at least 2 instructions on the
machine running the JVM to execute one JM machine instruction. Usually
the ratio is much higher. So, if you run Java by interpreting JM
instrudctions Java must be slower than if you had just compiled the
code to native code for the machine sitting on your desk :-)
Ok, so that kinda sucks...
So, instead of implementing the JVM as an interpreter implement it as
a compiler. Yes, you can take machine code for one machine and treat
it as a programming language. I mean, it is one, right?. So, you can
parse it, created a syntax tree for it, do semantic analysis, to
optimization, and compile it to the machine language of the machine on
your desk. Wow, what a concept! I ran into the concept back in the
'70s and it was old then. They did this sort of thing to move code
from the old IBM 1000 and 7000 series machines to run on the 360. I
remember a guy that made a small fortune by writing a compiler that
converted 1400 series machine code to COBOL so your could move it to
any machine with a COBOL compiler. Not that long ago IBM had a system
on their RISC machines that would let you run x86 code on them. They
hid a JIT compiler that convert x86 machine code to RISC code in the
bad instruction interrupt handler for.
So, instead of interpreting Java Machine code, you compile it to
native machine code. But, that could take a while so what you do is
compile it Just In Time. When you hit a new function you compile it
before you start running it. Better yet, since the compiler is sitting
there all the time and you most likely have an interpreter too you can
interpret code and only compile it when you see that it is going to be
run a lot. You know 10% of the code uses 90% of time. That means you
can do a crap job of compiling the code the first time and then go
back an optimize the parts that get used the most, and you can just
interpret some of the code. If you recompiled the whole program when
you run it you could find your self waiting a long time for the
program to run. This is especially true because in most java systems
at least part of the library is in JM code and it has to be compiled
to. Not just your code, but the system code has to be compiled at run
time.
So, a Java program can actually run faster the longer it runs. This is
great for long running processes like a web server, but not so great
for anything else.
OTOH, There are optimizing Java compilers for x86 and several other
architectures. You can just compile it all to native code, link it,
and run it just like you run C/C++.
Funny how that works. There is nothing about Java that forces you to
compile it to JM code and run it on a JVM that may or may not include
a JIT compiler.
This brings up one of my favorite pet peeves. I swear one of these
days I am going to put a round house kick up side the head of some
idiot who says, "Language XYZ is slow because it is an interpreted
language". *THERE IS **NO** SUCH THING AS AN INTERPRETED PROGRAMMING
LANGUAGE*. There are interpreters for languages. But, there are no
interpreted languages. A programming language is this neat
mathematical concept. It exists independent of any implementation. It
is a pure concept. Then someone has to implement it. You have choices
when you implement a language. You can compile it, or you can
interpret it, or you can do any combination in between. You can even
build an interpreter in hardware. That is all that machine code is
after all. Machine code is an interpreted language designed so that it
is easy to implement the interpreter in hardware. And even then large
parts of it may be implemented in microcode, and the microcode might
be implemented in nanocode. (I am not making that up!). There are a
lot of different ways create an instance of an implementation of a
programming language. An implementation may use a compiler or an
interpreter or anything in between. But, a programming language is
neither interpreted nor compiled because those words only apply to
implementations.
What about C#? Well MS called their phony machine code CIL for Common
Intermediate Language. It makes sense to use an intermediate language
instead making up a set of instructions for a machine that doesn't
exist the way Java did. Oh wait... MS calls it an intermediate
langauge, but they use that term for the assembly language of their
equivalent of the Java Virtual Mahcine. I guess of the Ph.D computer
science guys skipped that day in compiler writing class :-). Most
likely the learned compiler writing from the Dragon book so they were
never taught most of the really interesting things about compilers.
Ok, I stop being snarky and just say that there is no difference in
the way C# and the rest the .Net languages are implemented and the way
Java is implemented. None. Not a bit. Kinda cool that MS can now (in
theory) target their languages to any machine by implementing the
bottom layer of their system to the new machine and there is a chance
that all their applications will run on the new machine. Well... they
would run it they have also moved Windows to the new machine :-)
> then i just becomes sad that from the last 3 years i am just learning c++
> and all is waste...i cant even left c++ because i LOVE it whatever it is
> hard or not..
> Is that things about c# is true ??? c# is faster than c++ ?? In game
> development too???
Which language is "faster" is always a red hearing. There are few
cases where it means anything at all.
When they say that Java is faster than C++ they are usually comparing
grapes and gorillas. They are not as close as comparing apples and
oranges. First of they are talking about comparing languages when they
need to be talking about comparing implementations of programming
languages. You can't compare the performance of languages because they
aren't real things. You can only compare implementations. (Yeah,
another instance of my pet peeve.)
When it comes to determining which implementation of a language is
faster you have to pick identical tasks. Code them up using identical
algorithms. Compile them using... hmm no identical compilers... at
least compilers from the same company? A.... It is actually pretty
easy to compare the performance of say 5 different implementations of
C++ because you can find 5 different implementations to compare. And,
you can compare any number of different language implementations for
any number of languages if you can get someone to code up all the test
cases. And, even then it doesn't work very well. Why? Say one language
has a cool super-optimized Set implementation that makes it possible
to code the test in just 10 lines and uses the super optimized Set to
do all the work. Some other language has a no built in Set operation
so if you want to use the same algorithm you have to also code up Set
and oh by the way you are just using the first implementation you
found through google and wind up with a O(n) implementation. Well, in
that case, an interpreter can easily beat a compiler it the
interpreter is using the super optimized O(log n) implementation of
Set.
In reality the compiler that you spend the most time and money on will
almost always produce the best code. (But, not necessarily the fastest
code. The fastest code depends on the compiler and the programmers for
the application and all the libraries.) You can compare compiled code
by looking at how well the loops are flipped. How well they loops are
unrolled. How well common code sequences are removed. How much
strength reduction is done. And, a long list of other qualities. (You
can measure the final code for space, or for speed, but not both.) The
compiler you spend the most time and money working on is likely to be
the compiler that does the best on any kind of comparison. Performance
is a quality of an implementation, not the language. So to say that
Java is faster than C++ is much like asking the time honored question,
what happens when an irresistible force meets an immovable object. Or,
in terms we actually care about, who would win in a sumo wrestling
match, The Hulk, or The Thing? (I almost used the example of The Hulk
versus Superman, but that example can start a discussion that goes on
forever!) You see, to actually find out the answer you have to find an
instance of The Hulk, and an instance of The Thing and get them to
actually put on those silly sumo outfits and fight it out :-)
Anyway, for game programming most of the time consuming work is done
in the 3D graphics library, the sound Library, and the Physics
library. All that work is done by super optimized code and by special
hardware that is not invoked, but not generated, by the compiler you
are using. They work so fast that you can actually write perfectly
good games that run entirely in interpreters. Yep, most of the time,
if you do your job right, you code is only using a small percentage of
the CPU time and most of the rest of the work is being done in a GPU
that has dozens or hundreds of cores and is a 1000 times more powerful
(measured in Floating Point Multiplies Per Second) than you CPU.
So... lets have a nice conversation about all the things that grapes
and gorillas have in common.
Hey, I get to do this king of writing now because I have finally made
it all the way up to being an honest to GOD Associate Adjunct
Professor Ta DA! fan fair claping rubba rubba noises fade into the
background.
Perhaps I'm taking that to seriously?
Yeah.....
Bob Pendleton
>
> On Sun, Dec 12, 2010 at 5:13 PM, Paulo Pinto <pjmlp@xxxxxxxxxxxxx> wrote:
>>
>> That is why functional programming is slowly becoming mainstream.
>>
>> Multicore programming might just be the "killer feature" that will make
>> many
>> "normal" programmers care about it.
>>
>>
>> http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
>>
>> --
>> Paulo
>>
>> On Sun, Dec 12, 2010 at 10:44 AM, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
>>>
>>> I agree with that last statement bob. Especially since multiprocessing
>>> is becoming so important and it hasn't really been a topic that modern
>>> languages have tried to address that much.
>>>
>>> Change is on the horizon for that but not here yet
>>>
>>> On Dec 12, 2010 1:37 AM, "Bob Pendleton" <bob@xxxxxxxxxxxxx> wrote:
>>>
>>> On Sat, Dec 11, 2010 at 8:32 PM, Chris Nystrom <cnystrom@xxxxxxxxx>
>>> wrote:
>>> > On Sat, Dec 11, 2010 at...
>>>
>>> No, I do not.
>>>
>>> That is kind of like asking if C is the language that Algol should
>>> have been :-). But, a lot more complicated. The relationship between
>>> Java. C#, and C++ is very complicated. At a technical level I see both
>>> Java and C# as a reaction to the weird syntactic mess that C++ has
>>> become. But, you can't forget the history of J++ and C# in
>>> relationship to the half a billion dollars MS had to pay Sun for
>>> violating their contract. MS first tried to embrace and extend Java
>>> into an incompatible mess and when the court gave MS a half a billion
>>> dollar spanking for that MS then decided to invent C#. But, C# is
>>> *NOT* just a legal way to undermine Java. The C# designers did a good
>>> job and came up with a good language. But, not that good and being MS
>>> it is mostly only useful on Windows. To bad about that...
>>>
>>> I really think of Java and C# and experiments that may or may not lead
>>> to a language that is as powerful as C++ and Lisp but with a syntax
>>> that humans will actually be able to use and remember.
>>>
>>> We are a long way from being done with the invention of programming
>>> languages.
>>>
>>> Bob Pendleton
>>>
>>> >
>>> > Chris
>>> >
>>> > ---------------------
>>> > To unsubscribe go to http://gameprogrammer.com/mailinglist.ht...
>>>
>>> --
>>> +-----------------------------------------------------------
>>> + Bob Pendleton: writer and programmer
>>> + email: Bob@xxxxxxxxxxxxx
>>> + web: www.TheGrumpyProgrammer.com
>>>
>>> ---------------------
>>> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>>>
>>
>
>
>
> --
> -Dheeraj Patni
> LIVE AND LET LIVE
>
>
--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email: Bob@xxxxxxxxxxxxx
+ web: www.TheGrumpyProgrammer.com
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
