Author: Robert Hyatt
Date: 18:54:00 11/08/99
Go up one level in this thread
On November 08, 1999 at 17:36:10, Bruce Moreland wrote: >On November 08, 1999 at 14:55:47, Ratko V Tomic wrote: > >>> I agree that a good compiler (like MSVC) produces code on par with a good >>> assembly coder. >> >>Not even close. Namely, what you were comparing was: >> >>> I too have studied the code listings and tried to improve >>> it. Generally, there are only one or two instructions that can be tweeked, >>> and the speed up have never been large enough to be really measureable. >> >>That is not assembly coding (much less a good assembly coding) but trying to >>hand-simulate a C compiler (and as you noted, that's mostly a waste of time). >> >>The native assembly program (not a tweaked C compiler output) is for any >>resonably complex data manipulation (i.e. for other than just copying arguments >>to struct fields or pushing arguments and calling a function or other simple >>stuff) at least couple times faster than a compiler's output. In my consulting >>work I had over years optimized many times existent C/C++ code (for graphics, >>compression, encryption, search) by switching to the native assembly language >>algorithms in the critical portions of the task, ending up with 3-5 times faster >>critical sections. >> >>When you tailor the algorithm to the CPU architecture, you can use it much >>better, knowing well its strenghts and its limitations, than if you tailor it to >>a virtual C architecture and the compiler mechanically translates it to the >>actual CPU model. > >It is harder for chess since the programs tend to be very very heavily optimized >already, and you don't tend to find particularly bad bottlenecks. > >When I optimize performance I try to find the one function that is consuming all >of the time. It is very hard when you have 20 function, each of which is >consuming 5% of the time, and some guy has spent a week fiddling with each one >trying to make it faster already. > >bruce There was a discussion on r.g.c.c a couple of years ago about this. There are two ways to write assembler code: (1) do a 'conversion' using current C code as a model. This is an inefficient way to get something decent. I generally see modest improvements here, as in the 50% faster or so type improvement... (2) study the architecture carefully, and design the program to fit the architecture as closely as possible. I have seen 5x speedups by doing this. But it is a _lot_ of work. And is 100% non-portable. I would be surprised if someone did this and didn't get at least 2x faster than pure C, and I would hope for more. Optimizers are very good. But they are _nowhere_ as good as a human that knows the program... and knows about things that the compiler can't determine at all.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.