• janderson (49/49) Dec 26 2007 Here's a suggestion for D 3.0 which looks to me the time at which Walter...
• Don Clugston (11/18) Dec 26 2007 It's difficult to get much benefit from pre-fetching without significant...

janderson <askme me.com> writes:

Here's a suggestion for D 3.0 which looks to me the time at which Walter 
plans to hit modern processor design hard.  I could be part of the 
language or perhaps in a less elegant way in the standard lib.

Due to CPU speeds becoming ever more dependent on good cache 
optimizations I think something to make prefetching intuitive would be 
nice.  My attempt at this:

prefetch([array, value or class], [array, value or class], ...)
{
	//Code related to array, run as soon as prefetched data is ready
}
idle
{
	//Small Code to interleave in the prefetch or to do
	//while waiting for prefetch.  May occur at any time
	//while the above prefetch code block is being processed so
	//should be independent of the prefetch code (the compiler could
	//help verify the simple invalid cases).
	//
	//If possible the idle code could validate that it doesn't
	//cause cache misses itself.
	//
	//Also this should not cause context switching and should not
	//make the prefetch operation longer.
	//
	//Idle should always run (when is the question).
}


prefetch([array, value or class]);

Also an empty argument Prefetch(){...} idle {...} should work because 
idle can still be interleaved into the data in the prefetch's code section.

A class would be able to override its default .opPrefetch() method like:

class A
{
	B array[];

	void opPrefetch()
	{
		//Class A could potentially set up a cache if it wanted.
		prefetch(array);
	}
}

Class prefetches could potentially be called by the compiler at its 
digression, and the compiler could ignore the prefetch hint if it 
determines it knows better.

My thoughts:
Of course this is a architecture specific control structure and 
automatic determination is better.  However its not always possible for 
the compiler to know how a piece of code is intended to work.  I think 
that D is a practical language and pre-fetching is not going away 
anytime soon.

Other thoughts on the subject are welcome.

Don Clugston <dac nospam.com.au> writes:

janderson wrote:
 Here's a suggestion for D 3.0 which looks to me the time at which Walter 
 plans to hit modern processor design hard.  I could be part of the 
 language or perhaps in a less elegant way in the standard lib.
 
 Due to CPU speeds becoming ever more dependent on good cache 
 optimizations I think something to make prefetching intuitive would be 
 nice.

It's difficult to get much benefit from pre-fetching without significant 
experimentation. The normal fetching prediction mechanism for Pentium and AMD 
processors is very good, and most of the time, it's hard to beat. Examples
where 
it's beneficial are very hard to come by (at least, I've not seen any); 
normally, you're better off arranging your data so that the built-in
prefetching 
works correctly (this means things like, access data from low memory address to 
high memory, not in the reverse order).
There's much more to be gained by re-arranging data structures, rather than 
explicitly prefetching, I think.

Good sort of stuff to think about, though.