Re: High Level Language vs Assembly

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.

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