Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Looking for experienced C/C++ / ASM programmer

Reply
Thread Tools

Looking for experienced C/C++ / ASM programmer

 
 
Seebs
Guest
Posts: n/a
 
      11-06-2011
On 2011-11-05, Malcolm McLean <(E-Mail Removed)> wrote:
> If you're writing a video game, probably what you'll fund is that you
> need a function to normalise vectors for lighting, and that it's
> called millions of times and is a bottleneck. So to speed things up
> you need to express the normal as three signed chars, then write a
> rough and ready way of getting the length, which doesn't involve a
> call to square root. So it's a job for assembly. It's only one
> function, but it's absolutely vital that you have someone who can
> write it.


So far as I can tell, this post was probably accurate sometime in the early
90s, but isn't now. In particular, stuff like that is very, very, often done
in hardware, so you don't have to do that *at all* -- you merely tell the
hardware that you want some lighting, and whaddya know, there is lighting.

It's also not at all obvious that, even if you did need to write such a
thing, you would consistently find that hand-writing it in assembly was a good
choice. Even assuming that your video game runs only on x86 processors, like
those used in the Xbox 360 and PS3 -- whoops, those are both PowerPC, I was
thinking of the iPhone and iPad -- whoops, those are both ARM... You may well
find that you can't beat a compiler on well-written code to begin with.

Back in the 90s, we had people claiming that assembly was necessary for
performance-critical stuff in this group. At least one of them, admittedly
something of a twit, produced an example of a function which "needed" to be
in assembly for speed. His assembly code for it was, on real hardware,
noticably slower than at least one reasonably straightforward C
implementation.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-06-2011
On 2011-11-06, Seebs <(E-Mail Removed)> wrote:
> Back in the 90s, we had people claiming that assembly was necessary for
> performance-critical stuff in this group. At least one of them, admittedly
> something of a twit, produced an example of a function which "needed" to be
> in assembly for speed. His assembly code for it was, on real hardware,
> noticably slower than at least one reasonably straightforward C
> implementation.


I remember many years ago finding a very idiotic book in the library about
assembly language programming (Motorola 68000) on the Apple Mac.

The textbook presented a circle-drawing routine, and bragged about it only
takes a quarter second (don't remember the exact time unit) to draw a big
circle, thanks to being written in assembly language!

I thought, what? On the same machine, the classic MacPaint program draws fat
ellipses at a decent enough frame rate that you can interactively resize the
suckers. Haven't these authors ever used any applications on a Mac?

So I looked at what their routine was doing. It was using the naive algorithm
based on square root instead of Bresenham!
 
Reply With Quote
 
 
 
 
BGB
Guest
Posts: n/a
 
      11-06-2011
On 11/6/2011 12:40 AM, Seebs wrote:
> On 2011-11-05, Malcolm McLean<(E-Mail Removed)> wrote:
>> If you're writing a video game, probably what you'll fund is that you
>> need a function to normalise vectors for lighting, and that it's
>> called millions of times and is a bottleneck. So to speed things up
>> you need to express the normal as three signed chars, then write a
>> rough and ready way of getting the length, which doesn't involve a
>> call to square root. So it's a job for assembly. It's only one
>> function, but it's absolutely vital that you have someone who can
>> write it.

>
> So far as I can tell, this post was probably accurate sometime in the early
> 90s, but isn't now. In particular, stuff like that is very, very, often done
> in hardware, so you don't have to do that *at all* -- you merely tell the
> hardware that you want some lighting, and whaddya know, there is lighting.
>


well, there is a little more than that:
if one wants lighting that doesn't look like crap, then it is needed to
write pixel shaders / fragment shaders.

granted, these are typically in GLSL or similar.


> It's also not at all obvious that, even if you did need to write such a
> thing, you would consistently find that hand-writing it in assembly was a good
> choice. Even assuming that your video game runs only on x86 processors, like
> those used in the Xbox 360 and PS3 -- whoops, those are both PowerPC, I was
> thinking of the iPhone and iPad -- whoops, those are both ARM... You may well
> find that you can't beat a compiler on well-written code to begin with.
>


the option is, of course, to write different ASM versions for pretty
much any combination of OS and/or CPU one wants to run on.

so, ASM versions for:
Windows and Linux on x86;
Windows on x86-64;
Linux on x86-64;
XBox 360 (PPC);
PS3 (PPC);
iPhone and iPad (ARM);
Android (ARM).

the reason some targets for the same CPU are duplicated, is because
there are generally ABI differences between the targets (actually, there
are ABI differences between Windows and Linux on x86, but one can often
hedge around them).

if one is using an external assembler, then there is an issue that the
exact syntax will often vary from one assembler to another. likewise for
inline assembler (which is often compiler-specific).

the result is that often it is better to limit ASM to cases where the
task can't be effectively accomplished in C, which is usually because it
involves breaking through the normal language abstractions, and is
rarely particularly related to performance.


this is also partly why I use my own in-program assembler: I can better
control the ASM syntax (and most things I use ASM for wouldn't work so
well with static ASM anyways).

my stuff currently runs on a combination of Windows and Linux on x86,
x86-64, and ARM (although on ARM many things are disabled as I have not
yet ported the ASM-generation logic...).

in a few cases, I did make use of fallback pure-C logic (such as
handling "apply" via a giant procedurally-generated "switch()" block).
its limitation is that it only deals with certain argument types and
only currently supports up to 6 arguments or so (and produces a 200kB or
so object file).


> Back in the 90s, we had people claiming that assembly was necessary for
> performance-critical stuff in this group. At least one of them, admittedly
> something of a twit, produced an example of a function which "needed" to be
> in assembly for speed. His assembly code for it was, on real hardware,
> noticably slower than at least one reasonably straightforward C
> implementation.
>


yep.


I guess a question would be if there is any good way to apply an
arbitrary argument list (not known until runtime) against an arbitrary
function pointer, without needing a giant switch statement.

likewise goes for some way to produce a function pointer which can:
accept an arbitrary argument list (only known at runtime);
keep track of internal state.

the way I had generally handled this was to generate a thunk which would:
fold the arguments into an on-stack buffer;
keep track of a data-pointer given to it at construction;
call its attached function with the data-pointer and the arguments buffer.

generally, this was used to plug script-language functions into C
function pointers.

I have not yet come up with any "good" way to do this in pure C, apart
from generating arrays of dummy functions (and allocating from these),
and assigned pointers, and figuring out a good/portable way to do
0-argument varargs (normally, stdarg needs at least 1 fixed argument,
which is a problem in this case).


also, a number of other tasks roughly along these lines.


ASM is also sort of needed to implement a JIT, as otherwise one has an
interpreter which will generally run slower than native code, but very
often this is not a huge issue (where I need performance and where I am
using my scripting language don't really overlap all that much, so no
huge issue that it is an interpreter...).


most other things though are plain C though, as (generally) the C
compiler does a fairly decent job.

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      11-06-2011


"gwowen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Nov 4, 3:30 pm, BGB <(E-Mail Removed)> wrote:
>> > So, if you're going to talk chip-specific assembler, and you're not
>> > using an ARM instruction set, you're talking about a niche market.

>>
>> x86 is likely still most commonly used, even for assembler.

>
> By volume, ARM chips massively outsell x86 chips, and most of those
> are used on devices so diverse that each one will be require bespoke
> code - frequently in assembler (especially for the chips with little
> memory). The x86 chips will run Windows or some Unix-like OS, which
> means even the bespoke code will be compiled [C/C++/Fortran], byte-
> compiled [Java, C#] or interpreted (VB, Perl, Python).


I spend a lot of time messing with interpreters. I found that you need to
have a lot of assembly to achieve a decent execution speed; optimising
compilers are just not clever enough.

Once that's done, then actual applications will be written in the language
that's being interpreted.

But, someone has to be doing the assembly coding to start with though!
(Python in particular could have done with some instead of being in pure C.)

--
bartc



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for programmer experienced in Python/Django/Git/Unix TMChris Python 0 10-14-2009 09:09 PM
Experienced programmer: where to start with Java? Dave Java 9 10-25-2004 09:31 AM
web services tutorial/software for experienced programmer? Digital Puer Java 2 08-04-2004 12:31 PM
Experienced VB programmer trying to learn Java - Which IDE is best? Bill Java 7 07-23-2004 12:12 PM
looking for intro C text for experienced programmer Guy Middleton C Programming 3 09-01-2003 10:25 PM



Advertisments