MetaCall Polyglot is now available form D
Hey guys I am working on an open source polyglot called MetaCall which allows calling functions between languages. Recently a contributor has implemented support for DLang (Port), which means you can use MetaCall from D to call functions in C#, NodeJS, JavaScript, TypeScript, Ruby, Python, Cobol.. I would like to know what do you think about that, and if you see it useful for embedding other languages in D, for example to allow scripting to extend a project. Any feedback will be highly appreciated. I leave here the link of the repository: https://github.com/metacall/core If someone is interested in the D port you can find the source here: https://github.com/metacall/dlang-port
Re: On the D Blog: Lomuto's Comeback
On 8/4/20 9:49 AM, Andrei Alexandrescu wrote:
On 8/4/20 4:19 AM, Iain Buclaw wrote:
On 04/08/2020 03:14, Andrei Alexandrescu wrote:
Interesting, thanks!
Did a quick benchmark for n in `seq 1 10` ./lomuto.exe ${n}00...
[snip]
Looks good, so committing patch. :-)
Awesome, thanks! That does solve a puzzler I had while benchmarking.
I'm thinking the story of discovering and fixing this would be a great
follow-up in the blog. It doesn't quite mesh with Mike's current
introductory series, but it could be done as an intermezzo a la "Now For
Something Completely Different (And Much Lower Level)".
Sketch of an intro:
Upon reading "Lomuto's Comeback" in the D blog, I noticed the
performance were consistently juuust a bit worse for the D version than
for the C++ version for the same source code. My own measurements
confirmed the same. That bothered me at two levels. First, people
unfamiliar with the D language would form the opinion that D cannot
reach the efficiency of C++. Second, as the gdc creator and maintainer,
I knew for a fact the produced code must be literally identical. Any
difference would pin point a bug somewhere in the code generation
pipeline. So I set out to find it and fix it. This is the story of that
investigation, which will take us through looking through disassembly,
finding the culprit, devising a fix, confirming with measurements, and
patching the open-source gdc compiler.
...
Oh, and there are a few comments to the original blog post I'd be glad
to respond to in an appendix.
Re: On the D Blog: Lomuto's Comeback
On 8/4/20 4:19 AM, Iain Buclaw wrote:
On 04/08/2020 03:14, Andrei Alexandrescu wrote:
Interesting, thanks!
Did a quick benchmark for n in `seq 1 10` ./lomuto.exe ${n}00...
[snip]
Looks good, so committing patch. :-)
Awesome, thanks! That does solve a puzzler I had while benchmarking.
I'm thinking the story of discovering and fixing this would be a great
follow-up in the blog. It doesn't quite mesh with Mike's current
introductory series, but it could be done as an intermezzo a la "Now For
Something Completely Different (And Much Lower Level)".
Sketch of an intro:
Upon reading "Lomuto's Comeback" in the D blog, I noticed the
performance were consistently juuust a bit worse for the D version than
for the C++ version for the same source code. My own measurements
confirmed the same. That bothered me at two levels. First, people
unfamiliar with the D language would form the opinion that D cannot
reach the efficiency of C++. Second, as the gdc creator and maintainer,
I knew for a fact the produced code must be literally identical. Any
difference would pin point a bug somewhere in the code generation
pipeline. So I set out to find it and fix it. This is the story of that
investigation, which will take us through looking through disassembly,
finding the culprit, devising a fix, confirming with measurements, and
patching the open-source gdc compiler.
...
Re: Release of std.io v0.3.0
On Sunday, 26 July 2020 at 17:09:07 UTC, Steven Schveighoffer wrote: I have released a minor improvement to std.io [1], which adds support for opening the standard handles (stdin, stdout, stderr) [2]. I always hoped, since the stream package has been deprecated, that std.io will get merged into Phobos. Is that ever going to happen?
Re: On the D Blog: Lomuto's Comeback
On 04/08/2020 03:14, Andrei Alexandrescu wrote:
> Interesting, thanks!
>
Did a quick benchmark for n in `seq 1 10` ./lomuto.exe ${n}00...
gdc-baseline:
min_milliseconds=53.2922
median_milliseconds=56.8761
min_milliseconds=111.2512
median_milliseconds=115.5812
min_milliseconds=168.8659
median_milliseconds=174.9421
min_milliseconds=228.9230
median_milliseconds=235.9950
min_milliseconds=291.4758
median_milliseconds=302.2652
min_milliseconds=354.6598
median_milliseconds=360.3230
min_milliseconds=420.6221
median_milliseconds=424.0275
min_milliseconds=490.9294
median_milliseconds=505.0082
min_milliseconds=535.9912
median_milliseconds=556.0680
min_milliseconds=619.8160
median_milliseconds=629.6446
gdc-pr96429:
min_milliseconds=44.1008
median_milliseconds=46.2956
min_milliseconds=96.0864
median_milliseconds=99.4665
min_milliseconds=146.2498
median_milliseconds=151.5661
min_milliseconds=201.9479
median_milliseconds=207.0937
min_milliseconds=253.2555
median_milliseconds=265.6178
min_milliseconds=309.5941
median_milliseconds=317.8178
min_milliseconds=364.9312
median_milliseconds=381.9105
min_milliseconds=427.2581
median_milliseconds=437.9506
min_milliseconds=464.2838
median_milliseconds=482.9127
min_milliseconds=537.3167
median_milliseconds=550.9250
g++:
min_milliseconds=44.0164
median_milliseconds=46.5057
min_milliseconds=91.2730
median_milliseconds=97.8507
min_milliseconds=142.8459
median_milliseconds=153.4782
min_milliseconds=196.4765
median_milliseconds=202.1877
min_milliseconds=251.5876
median_milliseconds=261.6350
min_milliseconds=299.8530
median_milliseconds=311.0719
min_milliseconds=351.9959
median_milliseconds=370.0437
min_milliseconds=412.4231
median_milliseconds=420.1336
min_milliseconds=462.4810
median_milliseconds=474.2444
min_milliseconds=539.3359
median_milliseconds=541.5321
Looks good, so committing patch. :-)
