Re: for S'Image use Func??

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 11 May 2010 19:15:07 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Buffering = making copies. A copy is always an overhead. It pays off if  
> you
> have asynchronous components (use them in parallel), or components with
> high switching overhead, or faster memory (caching, indexing etc). If you
> don't have that it is just a loss.
As yoi said, there is caching, and even the good old i486 did have a  
cache. If you are to iterate on the X coming items of data and X is not so  
much a big number (otherwise, you may iterate on multiple buffers), then  
you benefit from the cache, which is otherwise loose as soon as you call  
the method which will read one more items and which will load its own  
state into the cache.

This is not so much special, near to all machines have a cache.

Also, on a stream, you will need a cache if you are to walk forward in the  
data stream (a stream is one way only, always forward, not backward).

As you were talking about checking that a particular optimization is  
really efficient or not, I can assert I've checked buffering improve  
performance on DOS running on i486 25 MHz. I remember of assembly or  
Pascal programs getting noticeably better performance as soon as they was  
relying on a buffer of at least 512 bits or more. There was a limit above  
which one increasing the buffer size was not increasing performance any  
more (if my mind is right, this was something like 2 Ki bytes)

On another application I'm working on actually, on Windows XP running on a  
faster machine (1 GHz CPU), better performance can be gain with buffer  
size above the latter : I've check the application is consuming about 30%  
less times for execution with 150 Ki buffer than with a rather small one.  
Giving it some even bigger buffer does not make so much difference.

It seems to me the faster the machine is, the higher you can increase  
buffers size.

Then, I feel you see copies where there are not more copies than with the  
way you suggest.

Given this

    Read one byte in a one byte variable
    Read one byte in a one byte variable
    Read one byte in a one byte variable
    Read one byte in a one byte variable
    Read one byte in a one byte variable

And then that

    Read five bytes in a five bytes buffer

Which one do make more copies than the other ? The answer is None, they  
both copy exactly five bytes.

The second one is not making more copy of anything, it is just using a  
bigger variable to store multiple items at once. So the matter then is  
“which is the best capacity for the buffer”. First answer is “depends on  
memory” (I'm not to say all memory may be used for that, just that there  
is a proportional relation) and the second answer is “check for it playing  
with buffer size and Ada.Calendar”.

There is also another point : it is mostly better, *when possible*, to do

    Batch OP1.1,OP1.2,OP1.3,OP1.4

    Batch OP2.1,OP2.2,OP2.3,OP2.4

instead of

    OP1.1
    OP2.1
    OP1.2
    OP2.2
    etc
    ...

The reason here again, is the CPU cache

This is something which is a bit related to the ability of an application  
or an algorithm to be re-design on top of parallelism. Here, instead of  
getting benefit from simultaneous execution, we get benefit from CPU cache  
(and nearly to all CPU have a cache).

Ah, an occasion to say the CPU cache also have another interesting effect  
peoples should know about : loop unroll is most of time anti-productive.  
If you enable the loop-unrolling “optimization” option of your compiler,  
please, check this is really relevant, don't just believe it (by the way,  
code-cache and data-cache do not exactly apply the same strategy, so don't  
infer code-cache performance beliefs from data-cache performance  
observations).


-- 
pragma Asset ? Is that true ? Waaww... great