[gameprogrammer] Re: RES: Re: C# vs C++

There is also "fast to program in" vs "have to code everything from
scratch".  Along this dimension:


   - Assembly language is very slow to write and debug, but can be very
   small and fast to execute
   - C/C++ is slow to write and debug if you do not have a good IDE and have
   no tools or libraries to start with
   - Java is considered faster because it has memory management, a memory
   model (helps with multi threading), and "clearer" exception handling than
   C++
   - BlitzMax is fast to write and debug because it provides many of the
   things that you may want to do in a game, but then you might hit the feature
   ceiling (multiplayer networked game?)

Also, there are "game engines" which can help you with the inner loop,
resource management, physics, etc.  This would make programming a game
faster.  You could also get faster by using a art asset tool chain, or
processes such as:

http://greyaliengames.com/blog/how-to-supply-art-ready-for-programmers/

But really, the question about "fast" depends on what kind of game are you
creating, which platforms, and how big, how pretty, how deep.

-Jason

On Mon, Feb 23, 2009 at 2:33 PM, Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:

> 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
>
>
>


-- 
Jason Harrison, PhD
Software Development
Human-Computer Interaction
Project Management

Cell: 604 644 8611
Email: drjasonharrison@xxxxxxxxx
LinkedIn: http://www.linkedin.com/in/drjasonharrison
Twitter: http://twitter.com/drjasonharrison

Thanks to Yggy King for bringing this quote to my attention:
Thinking the world should entertain you leads to boredom and sloth. Thinking
you should entertain the world leads to bright clothes, odd graffiti and
amazing grace in running for the bus. -- Ann Herbert

Other related posts: