[gameprogrammer] Re: C#
- From: Paulo Pinto <pjmlp@xxxxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Tue, 14 Dec 2010 10:21:40 +0100
Great reply!
I did spent too much time playing with compilers at the university and at
comp.compilers as well,
so it always baffles me to see people comparing languages without
understanding what goes
under the hood.
Congratulations for the Professor position as well.
Paulo
On Tue, Dec 14, 2010 at 3:21 AM, Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:
> 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:
