August 10

On Thursday, 8 August 2024 at 11:07:35 UTC, IchorDev wrote:

>

On Thursday, 8 August 2024 at 10:44:49 UTC, Renato Athaydes wrote:

>

Why shouldn't I cast the read result directly to immutable when it's literally impossible to get a reference to those bytes that is not immutable? It seems like the best way to achieve what I need.

You’re still violating the guarantees of immutability—data can’t go from mutable to immutable, that’s what const is for. Using const would be totally fine, or you can use .idup to create an immutable copy of the array.

Strictly speaking, you are allowed to cast from const/mutable to immutable if there is only one reference to the data in question:

>

A memory location can be transferred from thread-local to immutable or shared if there is only one reference to the location.

Source: https://dlang.org/spec/intro.html#memory-model

The recommended way to do this is to use the library function assumeUnique, since that communicates the intent of the code better than a naked cast.

August 10

On Saturday, 10 August 2024 at 00:44:29 UTC, Paul Backus wrote:

>

Strictly speaking, you are allowed to cast from const/mutable to immutable if there is only one reference to the data in question:

>

A memory location can be transferred from thread-local to immutable or shared if there is only one reference to the location.

Source: https://dlang.org/spec/intro.html#memory-model

Yes, it also says so in section 2 here. However, the function doesn’t guarantee or even promise that it returns the only mutable reference, so using an explicit cast cannot be guaranteed to be safe without manual verification. I think read’s POSIX implementation does return the only mutable reference, but I’m not that familiar with POSIX functions.

>

The recommended way to do this is to use the library function assumeUnique, since that communicates the intent of the code better than a naked cast.

Good point, I forgot about that.

August 17

On Sunday, 4 August 2024 at 20:14:50 UTC, Renato wrote:

>

Just announcing here in case someone may be interested in that (the code is very easy to read) and wants to give some feedback on my usage of D (I'm not experienced in D, just using it for some fun every now and then).

I wrote this also in Dart and Common Lisp as I was curious how D would compare to them.

Dart can parse libphobos.a in 1.3 seconds, and Common Lisp in around 1.5.
With D, it took only 0.4 seconds! And the code is actually the easiest to read IMHO.

A win for D :)

Both Dart and Common Lisp are pretty fast (for my usual needs, Lisp in particular is very, very fast for small scripts like this, sometimes beating Rust in my previous comparisons), so the bar was not too low as I see it. I am afraid the speedup may be due to D using mmap, and the other languages just reading the file in chunks. But my goal was not to make a fair benchmark!! It was to write the code for this in the most "natural" way that the language allowed... I used mmap in D because it's in the stdlib! In the other languages, it's possible only via libs. I might later convert D to use the exact same approach as in the other languages, just for curiosity... and I think that should be pretty easy, and if it is, it will prove to me that D really is a flexible language that makes it "easy" to modify code... will see.

I know I should also write it in Rust to feel more "convinced" to use D... but I am not sure I will bother because I already know Rust and I just don't feel like using it for anything (it's a combination of hard to write and modify code, ridiculous slow compile times even for small projects, but specially when using libs, which you need to for even the most basic stuff like proper error reporting etc....).

Anyway, in the unlikely case someone is curious about what code looks like in these 3 languages:

D: https://github.com/renatoathaydes/dar/blob/main/source/dar.d

Dart and Common Lisp: https://gist.github.com/renatoathaydes/54a93e91cacfafd08ad875f11615fbc2

August 17

On Saturday, 17 August 2024 at 19:05:22 UTC, Renato wrote:

>

On Sunday, 4 August 2024 at 20:14:50 UTC, Renato wrote:
I wrote this also in Dart and Common Lisp as I was curious how D would compare to them.

Dart can parse libphobos.a in 1.3 seconds, and Common Lisp in around 1.5.
With D, it took only 0.4 seconds! And the code is actually the easiest to read IMHO.

A win for D :)

Congrats! Which D compiler & flags did you use to test this BTW?

>

I might later convert D to use the exact same approach as in the other languages, just for curiosity... and I think that should be pretty easy, and if it is, it will prove to me that D really is a flexible language that makes it "easy" to modify code... will see.

D is generally pretty good for refactoring in my experience; except when you need to swap a class with a struct, which is when it gets a bit messy.

>

I already know Rust and I just don't feel like using it for anything (it's a combination of hard to write and modify code, ridiculous slow compile times even for small projects, but specially when using libs, which you need to for even the most basic stuff like proper error reporting etc....).

I tried to learn Rust myself, and it certainly didn’t inspire me to keep coming back for more.
I could see that a lot of Rust’s design patterns were clearly from the wish-lists of some long-time sufferers of C, but there were clearly a few lessons they never learned. For one, that snake_case and :: are just awful, genuinely so awful that their prevalence in Rust was very concerning to me. And for two, most programmers don’t want to have only one retained mutable reference at once; in fact many design patterns are completely impossible that way.
Before it was too late, I realised that Rust is where happiness goes to die, which didn’t make me feel like my prospects with it were very great. You don’t want to spend 10 years honing your skills in a language that makes you miserable, after all. So I gave up and kept searching back then, and here I am now.

>

Anyway, in the unlikely case someone is curious about what code looks like in these 3 languages:

D: https://github.com/renatoathaydes/dar/blob/main/source/dar.d

Dart and Common Lisp: https://gist.github.com/renatoathaydes/54a93e91cacfafd08ad875f11615fbc2

The Dart code looks less awful than I was expecting given its… progenitor. Shamefully, I cannot read Lisp for the life of me, despite being infatuated with the language’s design pattern, so I can’t comment on that one.

August 19

On Saturday, 17 August 2024 at 20:36:47 UTC, IchorDev wrote:

>

The Dart code looks less awful than I was expecting given its… progenitor. Shamefully, I cannot read Lisp for the life of me, despite being infatuated with the language’s design pattern, so I can’t comment on that one.

Dart is an excellent language and has been getting lots of very useful features lately, and its IDE/tooling support is next to none.

If it performed as well as D, honestly, I would use Dart for almost everything. My "main" working languages are Java and Kotlin (but I am tired of them and their build systems specially), and Dart is a bit closer than D to what I know... so it's much more comfortable for me to write it... OTOH I like how D "challenges" me more, and lets me write code about as low level as C if I want to, which those other languages don't.

Common Lisp for me is also about "challenging" myself. It's fun to write in the REPL (though you do need to get over the emacs initial learning curve... I've heard some people use the VSCode Lisp plugin as well but haven't tried it yet) and in projects where I want to quickly experiment and iterate, the REPL is very handy. But the language is a bit archaic, specially the tools around it like ASDF and Quicklisp... and the error reporting is pretty awful (to give you an idea, it's much worse than Java stacktraces).

Anyway, this may be interesting to language nerds like me :) if D attracts me, and others who like D have similar preferences as me, perhaps these other languages may be interesting to you guys as well.

August 19

On Monday, 19 August 2024 at 08:27:39 UTC, Renato wrote:

>

Anyway, this may be interesting to language nerds like me :) if D attracts me, and others who like D have similar preferences as me, perhaps these other languages may be interesting to you guys as well.

I was using Common Lisp before D. It was clearly from a different time period, which I blame on the language becoming standardized and the users bludgeoning anyone that dared to suggest things should be updated, since the language was divinely inspired. Names like set, setq, setf, princ, prin1, mapcar, mapcan, and mapl were more than I could handle.

I really liked Clojure. The problem was that you're stuck with the JVM, which for my work made it useless (they intentionally crippled C interop). Scheme is fun to use, but it always felt like it was missing functionality, and the code was fairly slow.

S-expressions have always felt like the natural way to write code. I've considered writing an s-expression syntax for D. Then I would be able to change the language if I didn't like it. (I know Walter's opinion on this, I just happen to disagree, because that strategy results in a good language for the guy that writes the compiler but less so for everyone else. I've always felt the main problem with Lisp was people writing bad code, not the things the language let you do.)

August 20

On Saturday, 17 August 2024 at 20:36:47 UTC, IchorDev wrote:

>

Congrats! Which D compiler & flags did you use to test this BTW?

I've just converted the code to use file random access, and it's about the same speed or maybe a bit slower than mmap.

Changing the D Code was as easy as it could be. No architectural changes required as something like Rust would definitely require.

I wasn't sure memory-mapped files would be faster, but it seemed easier to write the code based on that so I started with that... anyway, with random access (basically, File.rawRead and File.seek) it's a little harder to write, and the phobos lib is parsed in 0.110 secs with DMD (best of 3 tries, it varies a lot but second and third runs are much faster as I guess MacOS keeps the file's contents near memory?!), and 0.086 secs with LDC... very similar timings with the previous implementation, but that can go as low as 0.078 secs (within the "noise").

But using mmap was actually using a lot of memory, about as much memory as the size of the parsed file (~20MB) - perhaps I made a mistake the impl but I expected only the portion of the file I kept in memory at any time to remain in memory. With the random access impl, it used only 1.6MB of RAM.

Now, I am curious why D is so much faster than Dart (best time: 1.2 secs - and the Dart code is not even handling the file names properly with the BSD variant, which costs time to do) :D. I've run benchmarks before where Dart was quite a bit faster when compiled to a binary executable (it was basically a deep tree allocation problem, Dart just seems to be able to allocate memory much faster than D).

August 22

On Tuesday, 20 August 2024 at 19:53:40 UTC, Renato wrote:

>

Now, I am curious why D is so much faster than Dart

That’s why I’d really like to know what D compiler & flags you’re measuring the speed with. Like, is it really faster across the board, or only when using optimised LDC2 builds?
I can imagine the difference could also be to do with Dart’s libraries introducing some overhead, like always calling stat when loading a file for instance.
Also interestingly you say that Dart can allocate faster than D? D’s allocation speed is usually part of its performance advantage over other languages, since many other languages just use C’s malloc. Do you know what Dart’s allocator is?

August 22

On Thursday, 22 August 2024 at 14:17:52 UTC, IchorDev wrote:

>

On Tuesday, 20 August 2024 at 19:53:40 UTC, Renato wrote:

>

Now, I am curious why D is so much faster than Dart

That’s why I’d really like to know what D compiler & flags you’re measuring the speed with. Like, is it really faster across the board, or only when using optimised LDC2 builds?
I can imagine the difference could also be to do with Dart’s libraries introducing some overhead, like always calling stat when loading a file for instance.
Also interestingly you say that Dart can allocate faster than D? D’s allocation speed is usually part of its performance advantage over other languages, since many other languages just use C’s malloc. Do you know what Dart’s allocator is?

I use dub build --build=release, as explained in my project's README.

I don't know how Dart allocates, I presume it uses the JVM strategy of pre-allocating memory on the heap so each single allocation is practically free.

August 22

On Thursday, 22 August 2024 at 16:21:45 UTC, Renato Athaydes wrote:

>

I use dub build --build=release, as explained in my project's README.

That doesn’t tell me which compiler you’re using. It should say when you run dub, or if not you can see the commands it runs using -v. If it’s dmd then I guess Google must be hiring monkeys to sit at typewriters over there or something.

>

I don't know how Dart allocates

Oh well!