www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Referring to array element by descriptive name

reply albert-j <djftgls ifdflv.com> writes:
Is it possible to refer to an array element by a descriptive 
name, just for code clarity, without performance overhead? E.g.

void aFunction(double[] arr) {
     double importantElement = arr[3];
     ... use importantElement ...
}

But the above, I suppose, introduces an extra copy operation?
Jan 14 2017
next sibling parent tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Saturday, 14 January 2017 at 15:11:40 UTC, albert-j wrote:

 Is it possible to refer to an array element by a descriptive 
 name, just for code clarity, without performance overhead? E.g.

 void aFunction(double[] arr) {
     double importantElement = arr[3];
     ... use importantElement ...
 }

 But the above, I suppose, introduces an extra copy operation?


Unless the item type of that array is a complex like a big 
struct, copying basic types won't have much effect at all. You 
wouldn't notice it.

You could point to that element with a pointer:

double* importantElement = &arr[3];

But then you are going to define that pointer variable anyway. On 
top of that, for every access, instead of using the available 
data, CPU would look at the pointed memory address to get the 
value again and again (ignoring the cache).
Jan 14 2017
prev sibling next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Saturday, 14 January 2017 at 15:11:40 UTC, albert-j wrote:

 Is it possible to refer to an array element by a descriptive 
 name, just for code clarity, without performance overhead? E.g.

 void aFunction(double[] arr) {
     double importantElement = arr[3];
     ... use importantElement ...
 }

 But the above, I suppose, introduces an extra copy operation?


  Is the array always a fixed size? Or what?

  I wonder since you might get away with a union, or a struct that 
simply redirects the information appropriately. However it's a 
lot of writing for very little benefit at all.

  But honestly for as little loss you'll get of copying the one 
element and then copying it back (maybe if you change it) I doubt 
it will mean much if you just ignore trying to do a 0-cost 
aliasing as you are trying to do. You'd have to be doing it 
millions of times for such a copy to be noticeable.
Jan 14 2017
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 01/14/2017 07:11 AM, albert-j wrote:

 Is it possible to refer to an array element by a descriptive name, just
 for code clarity, without performance overhead? E.g.

 void aFunction(double[] arr) {
     double importantElement = arr[3];
     ... use importantElement ...
 }

 But the above, I suppose, introduces an extra copy operation?


I've used nested functions before. Compiled with

   -O -inline -boundscheck=off

even dmd produces exact code for the following three access methods:

import std.stdio;

void aFunction(double[] arr) {
     ref importantElement() {
         return arr[3];
     }
     writeln("Indexed element : ", arr[3]);
     writeln("importantElement: ", importantElement);

     double originalIdea = arr[3];
     writeln("Original idea   : ", originalIdea);
}

void main() {
}

Here are the three calls; comments added by me. The only difference is 
RCX vs. RAX for one of the calls:

.text._D6deneme9aFunctionFAdZv	segment
	assume	CS:.text._D6deneme9aFunctionFAdZv
_D6deneme9aFunctionFAdZv:
		push	RBP
		mov	RBP,RSP
		sub	RSP,010h
		mov	-010h[RBP],RDI
		mov	-8[RBP],RSI

; arr[3]
		mov	EDX,offset FLAT:_TMP0 32
		mov	EDI,012h
		mov	RSI,RDX
		mov	RAX,-8[RBP]
		movsd	XMM0,018h[RAX]
		call	  _D3std5stdio18__T7writelnTAyaTdZ7writelnFNfAyadZv PC32

; importantElement:
		mov	EDX,offset FLAT:_TMP0 32
		mov	EDI,012h
		mov	RSI,RDX
		mov	RCX,-8[RBP]
		movsd	XMM0,018h[RCX]
		call	  _D3std5stdio18__T7writelnTAyaTdZ7writelnFNfAyadZv PC32

; originalIdea:
		mov	EDX,offset FLAT:_TMP0 32
		mov	EDI,012h
		mov	RSI,RDX
		mov	RAX,-8[RBP]
		movsd	XMM0,018h[RAX]
		call	  _D3std5stdio18__T7writelnTAyaTdZ7writelnFNfAyadZv PC32


		mov	RSP,RBP
		pop	RBP
		ret
		0f1f
		add	byte ptr [RAX],0
		add	[RAX],AL
.text._D6deneme9aFunctionFAdZv	ends

Ali
Jan 14 2017
parent reply albert-j <djftgls ifdflv.com> writes:
Thank you for all your answers. I was concerned because I'm 
dealing with a small function that is called many times and where 
the bulk of the calculations in the simulation takes place. So 
even 5% performance difference would be significant for me. But 
it is good to know that compilers are smart enough to optimize 
this.
Jan 16 2017
parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Monday, 16 January 2017 at 19:03:17 UTC, albert-j wrote:

 Thank you for all your answers. I was concerned because I'm 
 dealing with a small function that is called many times and 
 where the bulk of the calculations in the simulation takes 
 place. So even 5% performance difference would be significant 
 for me. But it is good to know that compilers are smart enough 
 to optimize this.


  A while ago I had to deal with that fact, that the optimizations 
that it does over several levels is often better than my own. 
Using shifts which obfuscates that I was actually doing a divide. 
I tried writing a unique array handler to shave a few operations 
and save time, only to get no real benefit from it.
Jan 16 2017