Re: How does D’s ‘import’ work?
On Tuesday, 20 June 2023 at 17:56:27 UTC, Ali Çehreli wrote: On 6/20/23 08:09, Cecil Ward wrote: > I’m used to slow compilers on fast machines and compiling > gives me an excuse for more coffee and possibly fruity buns. Yes, all of us in past projects accepted C++'s slowness. We did get coffee, etc. One of my current colleagues regularly plays solitaire when waiting for C++ compilations. Not only it's not a professional sight, but C++ is proving to be a professional mistake. Nobody should suffer from such context switches. I have a hunch, without any backing research data, that C++'s contribution to humanity may be net negative. D is nothing like that: My turnaround is a few seconds: Write, compile, run, see the effect... I use only dmd partly because of laziness: it just works. Although I take full advantage D's low level powers, my programs have mostly been I/O bound with huge files, so dmd's less-than ideal optimization powers are hidden because most threads are waiting for file system I/O. Aside: std.parallelism and std.concurrency have been very helpful. Ali In the 1980s on our VAX 11/750, compile jobs were batch jobs placed in a queue. Half hour waits were not unknown. A build of the new o/s we were working on took around 40 mins on a 33 MHz 386 Dell PC (later a 486!) iirc. So time for patisserie even. But in oractice you simply got on with other jobs, like writing new code that was not yet integrated, code reviews, all sorts of things.
Re: How does D’s ‘import’ work?
On 6/20/23 08:09, Cecil Ward wrote: > I’m used to slow compilers on fast machines and compiling > gives me an excuse for more coffee and possibly fruity buns. Yes, all of us in past projects accepted C++'s slowness. We did get coffee, etc. One of my current colleagues regularly plays solitaire when waiting for C++ compilations. Not only it's not a professional sight, but C++ is proving to be a professional mistake. Nobody should suffer from such context switches. I have a hunch, without any backing research data, that C++'s contribution to humanity may be net negative. D is nothing like that: My turnaround is a few seconds: Write, compile, run, see the effect... I use only dmd partly because of laziness: it just works. Although I take full advantage D's low level powers, my programs have mostly been I/O bound with huge files, so dmd's less-than ideal optimization powers are hidden because most threads are waiting for file system I/O. Aside: std.parallelism and std.concurrency have been very helpful. Ali
Re: How does D’s ‘import’ work?
On Monday, 19 June 2023 at 16:24:03 UTC, rempas wrote: On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote: If I have sources to all the library routines, not libraries or .obj files. I am simply completely ignorant about the D tools including DUB, so off to do some reading. I’ve just been seeing how good LDC and GDC are, and the answer is extremely, especially LDC, which perhaps has a slight edge in code generation quality. I haven’t looked at AAarch64 code yet, only AMD64. Very impressed with all the work! Of course, DMD uses it's own custom backend so it's only fair to not expect for it to have the same runtime performance and optimizations as the other two compilers than use LLVM and GCC. If you only use x86_64, DMD will be amazing for your debug cycles! I’ve never used DMD. I don’t support that it will run on Aarch64. I’m running ldc on an ARM M2 Mac OSX. Also on x86-64 VMs at Godbolt.org but I must get access to an x86-64 box myself.
Re: How does D’s ‘import’ work?
On Sunday, 18 June 2023 at 21:51:14 UTC, Jonathan M Davis wrote: On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn wrote: I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.) In general, dmd is fantastic for its fast compilation speed. So, it works really well for developing whatever software you're working on (whereas ldc and gdc are typically going to be slower at compiling). And depending on what you're doing, the code is plenty fast. However, if you want to maximize the efficiency of your code, then you definitely want to be building the binaries that you actually use or release with ldc or gdc. - Jonathan M Davis Good point. I’m used to slow compilers on fast machines and compiling gives me an excuse for more coffee and possibly fruity buns. I’m incredibly impressed with LDC, GDC slightly less so, as it sometimes calls runtime library routines where Ldc doesn’t. Like in things to do with arrays, for one example. I hate calls to runtime library routines unless they are really substantial, mind you many calls to a modest-sized routine can get you a hotter cache, and even micro-op cache, and keep the whole code size down so as to improve cache overload or even pollution.
Re: How does D’s ‘import’ work?
On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote: If I have sources to all the library routines, not libraries or .obj files. I am simply completely ignorant about the D tools including DUB, so off to do some reading. I’ve just been seeing how good LDC and GDC are, and the answer is extremely, especially LDC, which perhaps has a slight edge in code generation quality. I haven’t looked at AAarch64 code yet, only AMD64. Very impressed with all the work! Of course, DMD uses it's own custom backend so it's only fair to not expect for it to have the same runtime performance and optimizations as the other two compilers than use LLVM and GCC. If you only use x86_64, DMD will be amazing for your debug cycles!
Re: How does D’s ‘import’ work?
On Monday, 19 June 2023 at 08:46:31 UTC, rempas wrote: On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote: target.obj: target.c include1.h include2.h cc.exe cc target.c and you either have to pray that you have kept the list of .h files that are mentioned inside target.c and other .h files referenced recursively from within these .h files etc. I listed the compiler as a dependency too, and I should really have a pseudo-target somehow that depends on the nature of the command line because changing the command line affects the generated code. If you have an automaking compiler that will generate the list of .h files then that’s so, so much safer. First of all, If we are talking about C files, D can import and compile them so you don't even need a Makefile! Now, if you need to compile C++ files and then either link or create a library (and link with it from the D project), then you can just run Dub in the end of the job in your make file! You can then have a variable called `DUB_FLAGS` in your Makefile and this is where the arguments that will be passed for the Dub will be. Will this be good enough for you? If I have sources to all the library routines, not libraries or .obj files. I am simply completely ignorant about the D tools including DUB, so off to do some reading. I’ve just been seeing how good LDC and GDC are, and the answer is extremely, especially LDC, which perhaps has a slight edge in code generation quality. I haven’t looked at AAarch64 code yet, only AMD64. Very impressed with all the work!
Re: How does D’s ‘import’ work?
On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote: target.obj: target.c include1.h include2.h cc.exe cc target.c and you either have to pray that you have kept the list of .h files that are mentioned inside target.c and other .h files referenced recursively from within these .h files etc. I listed the compiler as a dependency too, and I should really have a pseudo-target somehow that depends on the nature of the command line because changing the command line affects the generated code. If you have an automaking compiler that will generate the list of .h files then that’s so, so much safer. First of all, If we are talking about C files, D can import and compile them so you don't even need a Makefile! Now, if you need to compile C++ files and then either link or create a library (and link with it from the D project), then you can just run Dub in the end of the job in your make file! You can then have a variable called `DUB_FLAGS` in your Makefile and this is where the arguments that will be passed for the Dub will be. Will this be good enough for you?
Re: How does D’s ‘import’ work?
On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote: I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.) Other than the execution runtime, one other very important problem with DMD that wasn't refered is that is only support x86 and x86_64. LDC and GDC support LLVM's and GCC's architectures respectively.
Re: How does D’s ‘import’ work?
On Sun, Jun 18, 2023 at 03:51:14PM -0600, Jonathan M Davis via Digitalmars-d-learn wrote: > On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn > wrote: > > I wasn’t intending to use DMD, rather ldc if possible or GDC > > because of their excellent optimisation, in which DMD seems > > lacking, is that fair? (Have only briefly looked at dmd+x86 and > > haven’t given DMD’s back end a fair trial.) My experience with D for the past decade or so has consistently shown that executables produced by LDC or GDC generally run about 40% faster than those produced by DMD. Especially with CPU-intensive computations. This is just the hard fact. Of course, for some applications like shell-script replacements (which, incidentally, D is really good at -- once your script passes the level of complexity beyond which writing a shell script just becomes unmanageable), the difference doesn't really matter, and I'd use DMD just for faster compile times. The one thing the DMD backend is really good at, is compiling stuff *really* fast. LDC has been catching up in this department, but currently DMD still wins the fast compilation time race, by quite a lot. So it's very useful for fast turnaround when you're coding. But for release builds, LDC and GDC are your ticket. > In general, dmd is fantastic for its fast compilation speed. So, it > works really well for developing whatever software you're working on > (whereas ldc and gdc are typically going to be slower at compiling). > And depending on what you're doing, the code is plenty fast. However, > if you want to maximize the efficiency of your code, then you > definitely want to be building the binaries that you actually use or > release with ldc or gdc. [...] Yeah, LDC/GDC are really good at producing optimized executables, but they do take a long time to do it. (Probably 'cos it's a hard problem!) So for development -- DMD. For final release build -- GDC/LDC. T -- If it tastes good, it's probably bad for you.
Re: How does D’s ‘import’ work?
On Sunday, June 18, 2023 2:24:10 PM MDT Cecil Ward via Digitalmars-d-learn wrote: > I wasn’t intending to use DMD, rather ldc if possible or GDC > because of their excellent optimisation, in which DMD seems > lacking, is that fair? (Have only briefly looked at dmd+x86 and > haven’t given DMD’s back end a fair trial.) In general, dmd is fantastic for its fast compilation speed. So, it works really well for developing whatever software you're working on (whereas ldc and gdc are typically going to be slower at compiling). And depending on what you're doing, the code is plenty fast. However, if you want to maximize the efficiency of your code, then you definitely want to be building the binaries that you actually use or release with ldc or gdc. - Jonathan M Davis
Re: How does D’s ‘import’ work?
On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote: On Thursday, 8 June 2023 at 05:11:04 UTC, Ali Çehreli wrote: dmd's -makedeps command line switch should be helpful there. (I did not use it.) Ali I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.) LDC has the same feature with its --makedeps flag.
Re: How does D’s ‘import’ work?
On Thursday, 8 June 2023 at 05:11:04 UTC, Ali Çehreli wrote: On 6/7/23 21:17, Cecil Ward wrote: > I was thinking about the situation in C where I have a rule in a make > file that lists the .h files as well as the .c all as dependencies in > creating an object file. dmd's -makedeps command line switch should be helpful there. (I did not use it.) Ali I wasn’t intending to use DMD, rather ldc if possible or GDC because of their excellent optimisation, in which DMD seems lacking, is that fair? (Have only briefly looked at dmd+x86 and haven’t given DMD’s back end a fair trial.)
Re: How does D’s ‘import’ work?
On Sunday, 18 June 2023 at 17:34:51 UTC, rempas wrote: On Thursday, 8 June 2023 at 04:17:20 UTC, Cecil Ward wrote: I was thinking about the situation in C where I have a rule in a make file that lists the .h files as well as the .c all as dependencies in creating an object file. I don't think I'm aware of what you mean with "lists .h and .c files". Could you provide a small makefile that does that so I can run and examine? target.obj: target.c include1.h include2.h cc.exe cc target.c and you either have to pray that you have kept the list of .h files that are mentioned inside target.c and other .h files referenced recursively from within these .h files etc. I listed the compiler as a dependency too, and I should really have a pseudo-target somehow that depends on the nature of the command line because changing the command line affects the generated code. If you have an automaking compiler that will generate the list of .h files then that’s so, so much safer.
Re: How does D’s ‘import’ work?
On Thursday, 8 June 2023 at 04:17:20 UTC, Cecil Ward wrote: I was thinking about the situation in C where I have a rule in a make file that lists the .h files as well as the .c all as dependencies in creating an object file. I don't think I'm aware of what you mean with "lists .h and .c files". Could you provide a small makefile that does that so I can run and examine?
Re: How does D’s ‘import’ work?
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote: Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process. I do wonder why no-one have linked the [Modules and libraries](https://ddili.org/ders/d.en/modules.html) section in the [Programming in D](https://ddili.org/ders/d.en/index.html) book! The book is outdated in some things (and this isn't with logic, I have found one of these cases myself) but for most things, it will be ok!
Re: How does D’s ‘import’ work?
On 6/7/23 21:17, Cecil Ward wrote: > I was thinking about the situation in C where I have a rule in a make > file that lists the .h files as well as the .c all as dependencies in > creating an object file. dmd's -makedeps command line switch should be helpful there. (I did not use it.) Ali
Re: How does D’s ‘import’ work?
On Friday, 2 June 2023 at 12:07:09 UTC, rempas wrote: On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote: I have another question if I may, what do we do about getting makefiles right given that we have imports ? What do you mean with that? Give some more info please! I was thinking about the situation in C where I have a rule in a make file that lists the .h files as well as the .c all as dependencies in creating an object file.
Re: How does D’s ‘import’ work?
On Saturday, 3 June 2023 at 09:04:35 UTC, Dom DiSc wrote: You can replace your whole makefile by calling the compiler with -I (not always, but if you don't do funny things in your makefile). That would be `-i`. - This ability of the D compiler was just recently discovered (after -I was implemented for other reasons), but it relies on the fact that we have imports. Jonathan Marler implemented it in 2017 after a discussion in the forums. https://github.com/dlang/dmd/pull/7099
Re: How does D’s ‘import’ work?
On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote: I have another question if I may, what do we do about getting makefiles right given that we have imports ? You can replace your whole makefile by calling the compiler with -I (not always, but if you don't do funny things in your makefile). - This ability of the D compiler was just recently discovered (after -I was implemented for other reasons), but it relies on the fact that we have imports.
Re: How does D’s ‘import’ work?
On Friday, 2 June 2023 at 11:27:31 UTC, Andrew wrote: Others can correct me if I'm wrong, but I don't think that it is a priority for D to be specially compatible with makefiles in any way beyond the whole separation of compilation and linking. If he was talking about using GNU Make as a build system for D, then you are right! We have [dub](https://dub.pm/index.html) for that exact reason!
Re: How does D’s ‘import’ work?
On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote: I have another question if I may, what do we do about getting makefiles right given that we have imports ? What do you mean with that? Give some more info please!
Re: How does D’s ‘import’ work?
On Thursday, 1 June 2023 at 03:47:00 UTC, Cecil Ward wrote: I have another question if I may, what do we do about getting makefiles right given that we have imports ? Others can correct me if I'm wrong, but I don't think that it is a priority for D to be specially compatible with makefiles in any way beyond the whole separation of compilation and linking.
Re: How does D’s ‘import’ work?
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote: Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process. I do wonder why no-one have linked the [Modules and libraries](https://ddili.org/ders/d.en/modules.html) section in the [Programming in D](https://ddili.org/ders/d.en/index.html) book! The book is outdated in some things (and this isn't with logic, I have found one of these cases myself) but for most things, it will be ok!
Re: How does D’s ‘import’ work?
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote: Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process. I do wonder why no-one have linked the [Modules and libraries](https://ddili.org/ders/d.en/modules.html) section in the [Programming in D](https://ddili.org/ders/d.en/index.html) book! The book is outdated in some things (and this isn't with logic, I have found one of these cases myself) but for most things, it will be ok!
Re: How does D’s ‘import’ work?
On Wednesday, 31 May 2023 at 18:43:52 UTC, Cecil Ward wrote: Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process. I have another question if I may, what do we do about getting makefiles right given that we have imports ?
Re: How does D’s ‘import’ work?
On Wednesday, 31 May 2023 at 18:56:02 UTC, H. S. Teoh wrote: On Wed, May 31, 2023 at 06:43:52PM +, Cecil Ward via Digitalmars-d-learn wrote: Is there an explanation of how D’s ‘import’ works somewhere? I’m trying to understand the comparison with the inclusion of .h files, similarities if any and differences with the process. Unlike C's #include, `import` does NOT paste the contents of the imported file into the context of `import`, like #include would do. Instead, it causes the compiler to load and parse the imported file, placing the parsed symbols into a separate symbol table dedicated for that module (in D, a file == a module). These symbols are then pulled into the local symbol table so that they become available to code containing the import declaration. (There's a variation, `static import`, that does the same thing except the last step of pulling symbols into the local symbol table. So the symbols will not "pollute" the current namespace, but are still accessible via their fully-qualified name (FQN), i.e., by the form `pkg.mod.mysymbol`, for a symbol `mysymbol` defined in the module `pkg.mod`, which in turn is a module under the package `pkg`.) For more information: https://tour.dlang.org/tour/en/basics/imports-and-modules https://dlang.org/spec/module.html T Thank you so very much for the links and for your generous help. Some C compilers used to have a thing called ‘precompiled headers’, potential source of trouble and ai always felt uneasy about it rightly or wrongly. It’s great that D has got rid of header file includes though, they were ridiculously painful. I used to use the automake feature that was built into the JPI C compiler at work which took care of all the .h dependencies so you no longer had to worry about it. And you only loaded the compiler from disk and started it up once as it stayed in memory handling all the C parts of a make.
Re: How does D’s ‘import’ work?
On Wed, May 31, 2023 at 06:43:52PM +, Cecil Ward via Digitalmars-d-learn wrote: > Is there an explanation of how D’s ‘import’ works somewhere? I’m > trying to understand the comparison with the inclusion of .h files, > similarities if any and differences with the process. Unlike C's #include, `import` does NOT paste the contents of the imported file into the context of `import`, like #include would do. Instead, it causes the compiler to load and parse the imported file, placing the parsed symbols into a separate symbol table dedicated for that module (in D, a file == a module). These symbols are then pulled into the local symbol table so that they become available to code containing the import declaration. (There's a variation, `static import`, that does the same thing except the last step of pulling symbols into the local symbol table. So the symbols will not "pollute" the current namespace, but are still accessible via their fully-qualified name (FQN), i.e., by the form `pkg.mod.mysymbol`, for a symbol `mysymbol` defined in the module `pkg.mod`, which in turn is a module under the package `pkg`.) For more information: https://tour.dlang.org/tour/en/basics/imports-and-modules https://dlang.org/spec/module.html T -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth
