Re: Pre-expanding alloc cell(s) / reserving space for an associative array
On 7/9/23 4:24 PM, Cecil Ward wrote: Before I posted a question about avoiding unnecessary allocs/reallocs when adding entries to an array like so uint[ dstring ] arr; when I build it up from nothing with successive insertions. The array is accessed by a key that is a dstring. I was told that I can’t use .reserve or the like on it? Is that correct? My memory fails me, powerful pain drugs. Is there an alternate method I could use ? To be honest, the number of entries is likely to be extremely modest, so this is not a huge performance issue, six entries would be considered quite a lot. The string keys are probably not very very long. But I’m learning good habits for the day when I might have a bigger such database. No there is no such `.reserve` call for associative arrays. It might be possible to implement, but it's quite a bit different from a normal array reserve -- an associative array allocates all its elements as individual memory blocks, so there is no place to reserve things. You would have to add e.g. a free-list, that is reserved from the allocator itself. -Steve
Pre-expanding alloc cell(s) / reserving space for an associative array
Before I posted a question about avoiding unnecessary allocs/reallocs when adding entries to an array like so uint[ dstring ] arr; when I build it up from nothing with successive insertions. The array is accessed by a key that is a dstring. I was told that I can’t use .reserve or the like on it? Is that correct? My memory fails me, powerful pain drugs. Is there an alternate method I could use ? To be honest, the number of entries is likely to be extremely modest, so this is not a huge performance issue, six entries would be considered quite a lot. The string keys are probably not very very long. But I’m learning good habits for the day when I might have a bigger such database.
Re: Inlined functions and their original bodies - bloat
On Sunday, 9 July 2023 at 18:05:48 UTC, Cecil Ward wrote: This is with full -O3 optimisation try -fvisibility=hidden -release sux btw
Re: Inlined functions and their original bodies - bloat
On Sunday, 9 July 2023 at 18:04:13 UTC, Cecil Ward wrote: I have a program where the various routines are all marked pragma( inline, true ). The compiler obeys this but the LDC and GDC compilers still compile the function bodies even though the bodies are not needed as they are supposed to be ‘private’ to the module, explicitly marked as such, hoping that that is like static in C. There are no pointers to the routines, so no need for the bodies because of any indirect calls. Is there a way to control this code bloat in LDC / GDC ? Using the godbolt compiler explorer with LDC and GDC I can indeed see that the code is being inlined. Does this count as a compiler performance-type bug? This is with full -O3 optimisation and -release / -frelease for LDC and GDC respectively.
Re: Toolchain with ldc and AArch64 OSX
On Sunday, 9 July 2023 at 05:32:56 UTC, Danilo Krahn wrote:
On Saturday, 24 June 2023 at 15:16:37 UTC, Cecil Ward wrote:
I have LDC running on an ARM Mac. If anyone else out there is
an LDC or GDC user, could you knock up a quick shell program
to compile and link a .d file to produce an executable ? found
the linker but these tools are all new to me and a bit of help
would save me a lot of trial and error and frustration as I
try to find docs. GDC would be great too.
I have managed to achieve this before on a Raspberry Pi
AArch64 Linux Debian where the compiler can link and generate
an executable just in integrated fashion in the one command.
The OSX tools seem rather different however.
```d
import std.stdio : writeln;
void main() {
writeln("Hello, world!");
}
```
Compilation using LDC on macOS is just:
```
ldc2 --release --O3 main.d
```
Or some more options, to reduce executable size:
```
ldc2 --release --O3 --flto=full -fvisibility=hidden
-defaultlib=phobos2-ldc-lto,druntime-ldc-lto -L=-dead_strip
-L=-x -L=-S -L=-lz main.d
```
Executable size using first command: 1.3MB
Executable size using second command: 756KB
Brilliant, much appreciated! :) I posted ages ago about the bloat
that I see where function bodies are compiled even though they
are in fact always inlined and so the original body is never
needed. The address of these functions is not taken, so no
indirect pointer calling, and the functions are all explicitly
private which I hope is like static in C? Anyway, no one is
calling them from outside the module.
Re: Dynamic array of strings and appending a zero length array
On Saturday, 8 July 2023 at 20:01:08 UTC, H. S. Teoh wrote: On Sat, Jul 08, 2023 at 05:15:26PM +, Cecil Ward via Digitalmars-d-learn wrote: I have a dynamic array of dstrings and I’m spending dstrings to it. At one point I need to append a zero-length string just to increase the length of the array by one but I can’t have a slot containing garbage. I thought about ++arr.length - would that work, while giving me valid contents to the final slot ? Unlike C/C++, the D runtime always ensures that things are initialized unless you explicitly tell it not to (via void-initialization). So ++arr.length will work; the new element will be initialized to dstring.init (which is the empty string). T Many thanks, it might give me a slightly better result just doing ++arr.length;
Re: Weird template instantiation speed?
On Sunday, 9 July 2023 at 14:49:39 UTC, Steven Schveighoffer wrote: This is probably a bug somewhere, 4 seconds is too much. A reduced test case would be helpful. But I wanted to note, inside a struct template, the template name (by itself) is equivalent to the current instantiation. So just returning `BindingTempl` would be equivalent, and might not trigger this problem. See if that helps. -Steve Thank you for letting me know about being able to use `BindingTempl`, I had no idea! Unfortunately it doesn't mitigate the compile times, though. I forgot to mention, it only happens when specifying `-O` with DMD. LDC and GDC compile the same thing almost instantly. Boiling it down to a simple test is tough. If you remove a lot of components the struct template depends on then the compile time is too fast for anything to be noticeable. I think the issue is some kind of snowball-effect. If anyone wants to try to reproduce this issue: 1. Download [this exact commit](https://github.com/ichordev/bindbc-imgui/tree/65d02d68e4188250c948147a04a5820de3479a44) of the WIP BindBC-ImGui repo. (the newer commits won't compile) 2. Edit dub.selections.json to change `"bindbc-common"`'s version to `"0.0.6"`. 3. Run: ``` dmd -extern-std=c++11 -lib -O -version=BindImGui_Static -Isource/ -I~/.dub/packages/bindbc-common/0.0.6/bindbc-common/source/ source/bindbc/imgui/config.d source/bindbc/imgui/package.d source/imgui/impl.d source/imgui/package.d -v ``` 4. Now, remove `-O` from the dmd command. Blink and you'll miss it compiling!
Re: Linker error, doing something wrong?
On 7/9/23 10:01 AM, Dmitry Olshansky wrote: Trying to compile the following: https://github.com/DmitryOlshansky/photon/blob/master/tests/curl_download.d with: ldc2 curl_download.d -L-lcurl get: "__D6photon12__ModuleInfoZ", referenced from: __D13curl_download12__ModuleInfoZ in curl_download.o "__D6photon5macos4core2goFDFZvZv", referenced from: __D13curl_download4mainFZ13spawnDownloadMFAyaQdZv in curl_download.o "__D6photon5macos4core9startloopFZv", referenced from: __Dmain in curl_download.o "__D6photon9runFibersFZv", referenced from: __Dmain in curl_download.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: /usr/bin/cc failed with status: 1 Am I missing something? You need to link the library that contains photon. -Steve
Re: Weird template instantiation speed?
On 7/9/23 7:54 AM, IchorDev wrote: While working on some new bindings, I've discovered that if `opAssign` in a struct template "`BindingTempl(T)`" has the return type "`BindingTempl!T` then it adds about 4 seconds to the compile time per instantiation of `BindingTempl`. The added compile time is much lower if a function other than `opAssign` returns `BindingTempl!T`. Is opAssign a particularly bad operator to overload in templates or something? This is probably a bug somewhere, 4 seconds is too much. A reduced test case would be helpful. But I wanted to note, inside a struct template, the template name (by itself) is equivalent to the current instantiation. So just returning `BindingTempl` would be equivalent, and might not trigger this problem. See if that helps. -Steve
Linker error, doing something wrong?
Trying to compile the following: https://github.com/DmitryOlshansky/photon/blob/master/tests/curl_download.d with: ldc2 curl_download.d -L-lcurl get: "__D6photon12__ModuleInfoZ", referenced from: __D13curl_download12__ModuleInfoZ in curl_download.o "__D6photon5macos4core2goFDFZvZv", referenced from: __D13curl_download4mainFZ13spawnDownloadMFAyaQdZv in curl_download.o "__D6photon5macos4core9startloopFZv", referenced from: __Dmain in curl_download.o "__D6photon9runFibersFZv", referenced from: __Dmain in curl_download.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: /usr/bin/cc failed with status: 1 Am I missing something? -- Dmitry Olshansky https://olshansky.me
Re: Warning The package will no longer be detected starting from v1.42.0
On Monday, 26 June 2023 at 01:35:07 UTC, Soulsbane wrote:
Yeah, each folder under libs is a package and it's own git
repository. I think I'll just use the add-local approach. Kind
of a pain but getting spammed with a page of warnings every
compile is getting tiring :). Thanks a lot for the help Rikki
and Mathias
If your packages are all in the same folder, you could also use
path dependencies in your dub recipe, which saves the hassle of
manually doing `dub add-local` on new systems and dealing with
incompatible version tags:
```json
"dependencies": {
"your-package": {"path": "../your-package-repo/"},
},
```
Weird template instantiation speed?
While working on some new bindings, I've discovered that if `opAssign` in a struct template "`BindingTempl(T)`" has the return type "`BindingTempl!T` then it adds about 4 seconds to the compile time per instantiation of `BindingTempl`. The added compile time is much lower if a function other than `opAssign` returns `BindingTempl!T`. Is opAssign a particularly bad operator to overload in templates or something?
Re: Toolchain with ldc and AArch64 OSX
Forgot the following flags: `-L=-merge_zero_fill_sections -L=-no_exported_symbols -L=-no_eh_labels -L=-dead_strip_dylibs` So the full command is: ``` ldc2 --release --O3 --flto=full -fvisibility=hidden -defaultlib=phobos2-ldc-lto,druntime-ldc-lto -L=-dead_strip -L=-x -L=-S -L=-lz -L=-merge_zero_fill_sections -L=-no_exported_symbols -L=-no_eh_labels -L=-dead_strip_dylibs main.d ``` resulting in a executable of 588KB.
Re: `static` on module-level functions
On Friday, 7 July 2023 at 13:31:59 UTC, Steven Schveighoffer
wrote:
D allows no-op attributes in many cases because you can
possibly apply attributes to a group via `attribute:` or
`attribute { ... }`, and you may not want to fine-tune which
things can get the attribute to avoid errors.
Here's a fun one:
```d
enum foo() {
return "what?";
}
```
What does this mean? `enum` is a storage class, and any storage
class applied to a function is going to cause the function to
be inferred return type. So effectively, the `enum` does
nothing but take the place of `auto`. (`foo` is a function that
returns `string`)
However, I can't think of a valid reason to allow `static` on a
module-level scope. Applying static to a declaration at
module-level should be a no-op. So maybe that's one "use" of
static that can be eliminated.
-Steve
Ah yes, that's another beginner's trap—`enum` functions.
We should really make `enum` for functions mean "CTFE-only", or
something similar. Granted, you can *kinda* do that already with
lambda enums, as long as you make sure not to call them in
runtime code. However, enum templates can't be implicitly
instantiated from eponymous lambda parameters like with function
templates, and getting errors about "`__lambda7`" instead of
"`thisFnName`" isn't great either. As it is, it at least makes it
possible for BetterC code to use compile-time GC for mixin
generation, I just wish it was a little bit nicer.
