POD

[Nicolas Sicard]

On Saturday, 29 December 2012 at 01:53:15 UTC, David Nadlinger 
wrote:
>  - There are also possible performance implications: Structs 
> that just wrap a single field in order to enrich it with type 
> information, such as Duration or a Quantity struct from a units 
> of measurement library, will likely benefit from being passed 
> in registers (if available), even if they will probably have 
> constructors. In fact, having such one-field structs behave 
> like a naked value might be vitally important to be able to 
> decorate a C API with e.g. units information (even if such code 
> would strictly speaking be architecture dependent).
>
> As far as I can see – and I'm merely guessing based on the 
> isPOD comment here – the only reason for not just applying the 
> C/C++ definition in the obvious way might be a quirk in the DMD 
> backend implementation?

I had started but never finished such a wrapping struct for 
units, and I gave it another try recently 
(https://github.com/biozic/siunits).

Clearly, when using POD structs, the code of the function 
'quality' in examples/rlc.d, executes way more rapidly (5x) than 
using non-POD structs. The only difference between POD and 
non-POD in my tests is the presence of non-default constructors, 
which is versioned out in the POD version.

Code of the quality function with POD struct (compiled with -O 
-inline -release):
---
		push	RBP
		mov	RBP,RSP
		fld	tbyte ptr 020h[RBP]
		fld	tbyte ptr 010h[RBP]
		fld	tbyte ptr [0FFFFE77Ch][RIP]
		fmulp	ST(1),ST
		fld	tbyte ptr 030h[RBP]
		fmulp	ST(1),ST
		fdivp	ST(1),ST
		pop	RBP
		ret
---

Same code with the non POD version (same compiler flags):
---
		push	RBP
		mov	RBP,RSP
		sub	RSP,0B0h
		mov	RSI,[00h][RIP]
		lea	RDI,-040h[RBP]
		movsd
		movsd
		fld	tbyte ptr [0FFFFE5C4h][RIP]
		fstp	tbyte ptr -040h[RBP]
		mov	word ptr -036h[RBP],0
		mov	dword ptr -034h[RBP],0
		lea	RSI,-040h[RBP]
		lea	RDI,-050h[RBP]
		movsd
		movsd
		lea	RSI,-050h[RBP]
		lea	RDI,-060h[RBP]
		movsd
		movsd
		mov	RSI,[00h][RIP]
		lea	RDI,-030h[RBP]
		movsd
		movsd
		fld	tbyte ptr 010h[RBP]
		fld	tbyte ptr -060h[RBP]
		fmulp	ST(1),ST
		fstp	tbyte ptr -030h[RBP]
		mov	word ptr -026h[RBP],0
		mov	dword ptr -024h[RBP],0
		lea	RSI,-030h[RBP]
		lea	RDI,-070h[RBP]
		movsd
		movsd
		lea	RSI,-070h[RBP]
		lea	RDI,-080h[RBP]
		movsd
		movsd
		mov	RSI,[00h][RIP]
		lea	RDI,-020h[RBP]
		movsd
		movsd
		fld	tbyte ptr 030h[RBP]
		fld	tbyte ptr -080h[RBP]
		fmulp	ST(1),ST
		fstp	tbyte ptr -020h[RBP]
		mov	word ptr -016h[RBP],0
		mov	dword ptr -014h[RBP],0
		lea	RSI,-020h[RBP]
		lea	RDI,-090h[RBP]
		movsd
		movsd
		lea	RSI,-090h[RBP]
		lea	RDI,-0A0h[RBP]
		movsd
		movsd
		mov	RSI,[00h][RIP]
		lea	RDI,-010h[RBP]
		movsd
		movsd
		fld	tbyte ptr 020h[RBP]
		fld	tbyte ptr -0A0h[RBP]
		fdivp	ST(1),ST
		fstp	tbyte ptr -010h[RBP]
		mov	word ptr -6[RBP],0
		mov	dword ptr -4[RBP],0
		lea	RSI,-010h[RBP]
		lea	RDI,-0B0h[RBP]
		movsd
		movsd
		fld	tbyte ptr -0B0h[RBP]
		mov	RSP,RBP
		pop	RBP
		ret
---

I will use such a library in an environment that is not 
performance critical. But I hope that this will eventually be 
optimized.

Thanks,
Nicolas