Re: High Level Language vs Assembly

"T.Shackell" <ts3@ukc.ac.uk>
8 Mar 2001 12:27:25 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: High Level Language vs Assembly henry@spsystems.net (2001-02-25)
Re: High Level Language vs Assembly fjh@cs.mu.OZ.AU (2001-02-25)
Re: High Level Language vs Assembly ts3@ukc.ac.uk (T.Shackell) (2001-03-01)
Re: High Level Language vs Assembly samiam@cisco.com (Scott Moore) (2001-03-01)
Re: High Level Language vs Assembly samiam@cisco.com (Scott Moore) (2001-03-04)
Re: High Level Language vs Assembly sunni@speakeasy.net (Shankar Unni) (2001-03-04)
Re: High Level Language vs Assembly ts3@ukc.ac.uk (T.Shackell) (2001-03-08)
Re: High Level Language vs Assembly kszabo@nortelnetworks.com (Kevin Szabo) (2001-03-08)
Re: High Level Language vs Assembly tfjellstrom@home.com (Tom Fjellstrom) (2001-03-10)
Re: High Level Language vs Assembly samiam@cisco.com (Scott Moore) (2001-03-10)
Re: High Level Language vs Assembly bobduff@world.std.com (Robert A Duff) (2001-03-10)
Re: High Level Language vs Assembly mr@peakfive.com (Matt) (2001-03-10)
Re: High Level Language vs Assembly joachim_d@gmx.de (Joachim Durchholz) (2001-03-10)
[6 later articles]
| List of all articles for this month |

From: "T.Shackell" <ts3@ukc.ac.uk>
Newsgroups: comp.compilers
Date: 8 Mar 2001 12:27:25 -0500
Organization: University of Kent at Canterbury
References: 01-02-094 01-02-101 01-03-015 01-03-036
Keywords: optimize
Posted-Date: 08 Mar 2001 12:27:25 EST

Scott Moore <samiam@cisco.com> wrote:


> And interestingly, the next level of performance optimization is to go
> back to high level language, that is, using "online" compilation. The
> idea is that you build an assembly program while running just to solve
> the problem with all the parameters at hand. For example, you have a
> series of graphic figures to draw, you can make a general C routine,
> an assembly routine, or you can generate a section of assembly
> (actually machine) code that specifically draws the
> figures. Generating it is costly, but pays off in long redundant
> sequences.


Intresting I haven't heard of using this style of autogenerated code
for this. So the idea is you generate a section of machine code for a
complete 3D object? However I do not follow your logic.


The vast majority of the time cost for a realtime 3D engine is in the
rasterizer. A hand coded assembler 'any triangle' rasterizer can
always beat a compiler generated one. The only way autogenerated code
can win out is to autogenerate code for a specific triangle as apposed
to a general one (I think this is what you're saying?). however
triangles are parameterized on


- object position
- object orientation
- camera position
- camera orientation
- current texture (for multiply textured objects)
- current animation frame (for animated objects)
- position relative to potentially moving lights
- orientation relative to potentially moving lights
- what objects are infront of another (for semi-transparent objects)
- ... and possibly others


This is a staggering number of possible variations (bearing in mind
most of these quantities are stored in multiple 32 bit numbers). In a
realtime 3D engine most of these parameters are changing constantly
and hence the specific code would have to be generated, run once and
then discarded. This is not going to give a performance increase.


If the autogeneration is to do with more general things such as vertex
positions and texture coordinates then this does not give a
performance increase either because a general triangle rasterizer is
still needed and is still the bottleneck of the system (a software
rasterizer will generally use 90+% of the CPU time) and, as I said, a
compiler generated general triangle rasterizer can always be beaten by
a hand generated ASM one.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.