Re: Static array initialisation
On Wednesday, 31 March 2021 at 17:27:44 UTC, DLearner wrote: Hi I did: immutable uint MemSize=100; // Memory size in bytes. // Memory Pool ubyte[MemSize] MemPool = 8; And had a look in memory. I think the compiler set up 101 '8's, not 100 in memory. Which I did not expect. Best regards It's a bit interesting though. The behavior seems to vary a bit between compilers. DMD: ubyte[100] example.MemPool: db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,008h,008h,008h,008h ; db 008h,008h,008h,008h,000h,000h,000h,000h ; db 000h,000h,000h,000h,000h,000h,000h,000h ; LDC: ubyte[100] example.MemPool: .zero 100,8 GDC: ubyte[100] example.MemPool: .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 .byte 8 As you can see, all have 100 valid values, but DMD seems to be aligning to a multiple.
Re: Static array initialisation
On Wednesday, 31 March 2021 at 17:54:38 UTC, DLearner wrote: On Wednesday, 31 March 2021 at 17:46:25 UTC, Imperatorn wrote: On Wednesday, 31 March 2021 at 17:27:44 UTC, DLearner wrote: Hi I did: immutable uint MemSize=100; // Memory size in bytes. // Memory Pool ubyte[MemSize] MemPool = 8; And had a look in memory. I think the compiler set up 101 '8's, not 100 in memory. Which I did not expect. Best regards When I look there are 100. What makes you think there are 101? I printed bytes from &MemPool[0] to just beyond &MemPool[99}. Can you show the print function? Maybe the problem lies there?
Re: why use string for this example of appender?
On 3/31/21 5:32 PM, ludo wrote:
Hi guys,
I am working on an old software in D1, which defines at some point an
array.d module. See my github file: https://tinyurl.com/5ffbmfvz
If you go line 347, you see an ArrayBuilder struct, which is supposed to
behave exactly like an array but with faster concatenation. The class
comment says:
/**
* Behaves the same as built-in arrays, except about 6x faster with
concatenation at the expense of the base pointer
* being 4 system words instead of two (16 instead of 8 bytes on a 32-bit
system).
*/
I created a unittest, line 586, to test this statement. You can git
clone + dub test, to see the result. On my machine I get:
*** ArrayBuilder benchmark ***
1) Concatenation with std: 745 μs and 7 hnsecs
2) Concatenation with Arraybuilder: 236 μs and 8 hnsecs
3) Concatenation with Reserve: 583 μs and 5 hnsecs
4) Concatenation with Length: 611 μs and 8 hnsecs
5) Concatenation with Appender: 418 μs
In (1) I use standard array concatenation, in (2) I use the ArrayBuilder
struct, in (3) I test standard concat with a call to reserve()
before-hand, in (4) standard + length= beforehand, and finally I dug out
the Appender class in (5).
None of the D library tools beat the ArrayBuilder class! Note though,
that Appender is only two times slower, not 6x slower.
Can someone explain to me why ArrayBuilder is so fast (or the others so
slow)? What is this base pointer being "4 system words instead of 2"? I
read the code of ArrayBuilder, but I can not spot any magic trick... Has
this anything to do with standard array concat being "safer"
(thread-wise, bounds-wise, etc)?
ArrayBuilder should be similar in performance to Appender. I think part
of the issue with appender could be the ref counted design. Only 1000
elements is going to show heavily the setup/teardown time of allocation
of the implementation struct. But that is a guess. You may want to up
the repetition count to 100 or 1000.
Note your code for appending with length is not doing what you think:
void concat_withLength()
{
int[] array;
array.length = 1000;
for (int j=0; j<1000; j++)
array ~= j;
}
This allocates 1000 elements, and then append 1000 *more* elements.
I think you meant in the loop:
array[j] = j;
This should be the fastest one.
-Steve
Re: why use string for this example of appender?
Hi guys, I am working on an old software in D1, which defines at some point an array.d module. See my github file: https://tinyurl.com/5ffbmfvz If you go line 347, you see an ArrayBuilder struct, which is supposed to behave exactly like an array but with faster concatenation. The class comment says: /** * Behaves the same as built-in arrays, except about 6x faster with concatenation at the expense of the base pointer * being 4 system words instead of two (16 instead of 8 bytes on a 32-bit system). */ I created a unittest, line 586, to test this statement. You can git clone + dub test, to see the result. On my machine I get: *** ArrayBuilder benchmark *** 1) Concatenation with std: 745 μs and 7 hnsecs 2) Concatenation with Arraybuilder: 236 μs and 8 hnsecs 3) Concatenation with Reserve: 583 μs and 5 hnsecs 4) Concatenation with Length: 611 μs and 8 hnsecs 5) Concatenation with Appender: 418 μs In (1) I use standard array concatenation, in (2) I use the ArrayBuilder struct, in (3) I test standard concat with a call to reserve() before-hand, in (4) standard + length= beforehand, and finally I dug out the Appender class in (5). None of the D library tools beat the ArrayBuilder class! Note though, that Appender is only two times slower, not 6x slower. Can someone explain to me why ArrayBuilder is so fast (or the others so slow)? What is this base pointer being "4 system words instead of 2"? I read the code of ArrayBuilder, but I can not spot any magic trick... Has this anything to do with standard array concat being "safer" (thread-wise, bounds-wise, etc)? And also, is there a std module which performs as well, some Fast Appender class? Could not find any. Thanks
Re: Static array initialisation
On 3/31/21 2:03 PM, DLearner wrote: On Wednesday, 31 March 2021 at 18:00:32 UTC, Steven Schveighoffer wrote: The answer is no, the compiler does not write to memory beyond the 100 elements. That memory *might* happen to have an 8 in there. That's not proof of anything though. I entirely agree - I wasn't saying anything was wrong, but I _was_ surprised. Not least because it's not chance, I changed the initial value and the effect repeated with the new value. It's by chance, the only correlation is probably that you are looking at stack data that was set up to call the function that initialized the static array. Maybe it's saving some registers and the register happens to contain 8 (not surprising). Or some other reason. Again, you are looking at data that the array doesn't own, and therefore the compiler can put anything in there, it could be 42 on another compiler, on another platform, or maybe if you call some other functions first, it changes. -Steve
Re: Static array initialisation
On Wednesday, 31 March 2021 at 18:00:32 UTC, Steven Schveighoffer wrote: On 3/31/21 1:54 PM, DLearner wrote: On Wednesday, 31 March 2021 at 17:46:25 UTC, Imperatorn wrote: On Wednesday, 31 March 2021 at 17:27:44 UTC, DLearner wrote: Hi I did: immutable uint MemSize=100; // Memory size in bytes. // Memory Pool ubyte[MemSize] MemPool = 8; And had a look in memory. I think the compiler set up 101 '8's, not 100 in memory. Which I did not expect. Best regards When I look there are 100. What makes you think there are 101? I printed bytes from &MemPool[0] to just beyond &MemPool[99}. When you look beyond the bounds of where you have access to, you are bound to see just about anything. The answer is no, the compiler does not write to memory beyond the 100 elements. That memory *might* happen to have an 8 in there. That's not proof of anything though. -Steve I entirely agree - I wasn't saying anything was wrong, but I _was_ surprised. Not least because it's not chance, I changed the initial value and the effect repeated with the new value.
Re: Static array initialisation
On 3/31/21 1:54 PM, DLearner wrote: On Wednesday, 31 March 2021 at 17:46:25 UTC, Imperatorn wrote: On Wednesday, 31 March 2021 at 17:27:44 UTC, DLearner wrote: Hi I did: immutable uint MemSize=100; // Memory size in bytes. // Memory Pool ubyte[MemSize] MemPool = 8; And had a look in memory. I think the compiler set up 101 '8's, not 100 in memory. Which I did not expect. Best regards When I look there are 100. What makes you think there are 101? I printed bytes from &MemPool[0] to just beyond &MemPool[99}. When you look beyond the bounds of where you have access to, you are bound to see just about anything. The answer is no, the compiler does not write to memory beyond the 100 elements. That memory *might* happen to have an 8 in there. That's not proof of anything though. -Steve
Re: Static array initialisation
On Wednesday, 31 March 2021 at 17:46:25 UTC, Imperatorn wrote: On Wednesday, 31 March 2021 at 17:27:44 UTC, DLearner wrote: Hi I did: immutable uint MemSize=100; // Memory size in bytes. // Memory Pool ubyte[MemSize] MemPool = 8; And had a look in memory. I think the compiler set up 101 '8's, not 100 in memory. Which I did not expect. Best regards When I look there are 100. What makes you think there are 101? I printed bytes from &MemPool[0] to just beyond &MemPool[99}.
Re: Static array initialisation
On Wednesday, 31 March 2021 at 17:27:44 UTC, DLearner wrote: Hi I did: immutable uint MemSize=100; // Memory size in bytes. // Memory Pool ubyte[MemSize] MemPool = 8; And had a look in memory. I think the compiler set up 101 '8's, not 100 in memory. Which I did not expect. Best regards When I look there are 100. What makes you think there are 101?
Static array initialisation
Hi I did: immutable uint MemSize=100; // Memory size in bytes. // Memory Pool ubyte[MemSize] MemPool = 8; And had a look in memory. I think the compiler set up 101 '8's, not 100 in memory. Which I did not expect. Best regards
How use WinUI with Dlang?
There is a way for create modern windows GUI with WinUI and Dlang?
Re: Derived type
On Wednesday, 31 March 2021 at 12:09:33 UTC, Basile B. wrote: yeah template instances are identified using the parameters identifiers, then the alias is just a syntactic shortcut to that, not producing a new symbol with a unique mangle... so, no way to generate struct with parametrized name by template or mixin template? That being said you can still use a string mixin if the messages have to be correct ... thank you!
Re: Derived type
On Wednesday, 31 March 2021 at 04:49:50 UTC, novice3 wrote:
On Tuesday, 30 March 2021 at 21:53:34 UTC, Basile B. wrote:
struct Typedef(TBase)
{
TBase payload;
alias payload this;
}
alias Xobj = Typedef!(void*);
This is how std.typecons.Typedef made, IMHO.
The problem is this code generate struct with name
"Typedef!(void*)",
then compiler show this name (not "Xobj") in messages:
https://run.dlang.io/is/eEI2yC
void* bad;
foo(bad);
Error: function foo(Typedef!(void*) obj) is not callable using
argument types (void*)
cannot pass argument bad of type void* to parameter
Typedef!(void*) obj
yeah template instances are identified using the parameters
identifiers, then the alias is just a syntactic shortcut to that,
not producing a new symbol with a unique mangle... but the
message is correct assuming you want void* to be rejected.
That being said you can still use a string mixin if the messages
have to be correct
---
string genTypeDef(TBase)(string name)
{
return "struct " ~ name ~ "{" ~ TBase.stringof ~ " payload;
alias payload this;}";
}
mixin(genTypeDef!(void*)("Xobj"));
void foo (Xobj obj) {}
---
Re: Contributing CDF bindings to Deimos
On 2021-03-25 05:00, Chris Piker wrote: I've attempted to follow all guidelines as best I understood them, but this is my first package. It likely has some style and functionality issues. There's a general convention to name the top level module or package the same as the project. To avoid causing conflict with other projects. I see that you have used DStep to create the bindings. I also see that you had to make some changes to the output. Please report any issues or enhancement requests to [1]. I you need any DStep specific help or have any questions, please ask here in the learn forum or on the DStep specific discussions section (which I just enabled) on GitHub [2]. I'll do my best to help you. [1] https://github.com/jacob-carlborg/dstep [2] https://github.com/jacob-carlborg/dstep/discussions -- /Jacob Carlborg
