What is ....

[Alma J Wetzker]

Roger Oberholtzer wrote:
> On Fri, 2006-02-10 at 07:38 -0600, Ben Duncan wrote:
> 
>>Ok, you have my FULL attention now Kurt ...
>>
>>Anyway, a multi value is designed to use variable length fields in
>>a variable length record format , Hence the statement in it is
>>relatively space efficient. Using only what it needs without any
>>pre-defined format for data layout.
>>
>>However, as I uderstand it (;->) a "file manger" using the
>>ext2/3 or other, is going to be constrained by the inode/block
>>allocation for access, no? Meaning read's and writes are going to
>>some form of the physical "page" size the system uses regardless of
>>actual bytes in use in a file (is this correct?)
>>
>>Now, on using bit map's, how does one go about keeping them
>>in the CPU or even L1 cache, or is that automatic (or do you use the
>>REGISTER type?)
> 
> 
> I think the register type modifier is not so useful these days.
> Compilers are very good at putting oft used variables in registers. In
> fact, some compilers silently ignore the register modifier and decide on
> their own where to store variables.
> 
> I doubt a user program can do very much to keep things in the cache.
> Remember that Linux is multi-tasking OS, so other processes will also
> use the cache.
> 
> Your best bet is to try program profiling. This can help you locate
> candidate code for improvement. Things like using inline code rather
> than #define macros. There are a few things that you can do that can
> make a big improvement. But profiling is a start.
> 
> Also, intel claim that their C/C++ compiler can produce code that is 20%
> faster than GNU gcc, while remaining source and binary compatible. If
> speed is an issue, this could be something to consider. We are currently
> evaluating intel's claims in an image processing project. No details
> yet.

That is certainly true for general applications these days.  Modern 
compilers can optimize much better than any but the best assembly 
language programmers.

However, this semester I am working on embedded processors and DSP 
implementations on FPGAs.  That is far from what Ben is doing, but still 
vital stuff for device drivers and other "glue" applications.  DSP in 
particular, is not a well understood problem so optimizations are often 
counterproductive in the overall design.  In these cases, you need to go 
into the generated code and do some tweaking.

In business applications, all the low level stuff is generally not 
applicable, except where you can implement an elegant solution because 
you know.  Those chances are _RARE_.  Studies show that most programmers 
don't use more that 20% of a language's possibilities anyway, so why 
implement redundant ways of doing the same thing?

     -- Alma