On 05/06/2015 23:07, Iain Buclaw via Digitalmars-d wrote:
On 5 Jun 2015 20:55, Bruno Medeiros via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:
[...]
This isn't the first time I've seen
On 2015-06-03 12:37, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
Now really? C was designed at a time where you couldn't even hold the
source file in memory, so there is not even a need for an explicit AST.
C can essentially be streamed in separate passes:
On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:
[...]
This isn't the first time I've seen this, in basically every benchmark
featuring D I have to submit a patch/make a comment that dmd shouldn't
be used. Make no mistake, this is damaging to D's reputation - how
well does D's native
On 5 Jun 2015 20:55, Bruno Medeiros via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:
[...]
This isn't the first time I've seen this, in basically every benchmark
featuring D I have to submit a patch/make a comment that dmd
On Friday, 5 June 2015 at 22:07:48 UTC, Iain Buclaw wrote:
On 5 Jun 2015 20:55, Bruno Medeiros via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d wrote:
[...]
This isn't the first time I've seen this, in basically
every benchmark
On 6 June 2015 at 01:20, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 5 June 2015 at 22:07:48 UTC, Iain Buclaw wrote:
On 5 Jun 2015 20:55, Bruno Medeiros via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 29/05/2015 19:35, H. S. Teoh via Digitalmars-d
On Thursday, 4 June 2015 at 03:04:31 UTC, ketmar wrote:
On Wed, 03 Jun 2015 12:20:28 +, Paulo Pinto wrote:
Now really? C was designed at a time where you couldn't even
hold the
source file in memory, so there is not even a need for an
explicit AST.
C can essentially be streamed in
ketmar ket...@ketmar.no-ip.org writes:
yes, i remember lightning fast compile times with turbo pascal. yet the
code it produced was really awful: it was even unable to fold constants
sometimes!
I remember it being in a single DOS .COM (was it TURBO.COM?) only about
40k which included the
On Wednesday, 3 June 2015 at 07:50:53 UTC, Paulo Pinto wrote:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
Project size is irrelevant here. I had 500 line C++ project
that took 10 minutes to compile (hello boost::spirit). It is
impossible for C++ to compile faster than D by
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
Project size is irrelevant here. I had 500 line C++ project
that took 10 minutes to compile (hello boost::spirit). It is
impossible for C++ to compile faster than D by design. Any time
it seems so you either aren't comparing same thing
sure what you mean. A theoretical compiler doesn't matter; what
actual compilers do does.
Of course it does, it defines how far you can go in a concurrent
build process before hitting an unsurpassable bottle-neck.
(not that I personally care, as I find both C++ and D compilers
to be fast
There are lots of features in D, that C++ does not have, that
will make separate compilation and partial
evaluation/incomplete types difficult. So C++ is faster than D
by design, even when the compiler isn't.
I've tried to parse that last sentence a few times and I'm not
sure what you mean.
On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:
it can get even better if you properly modularize your projects
instead of having 1-2 files that build slow, which causes a lot
of waiting.
Yes, sure. You can probably get the same build speeds as with C
if you organize your code in
On Wednesday, 3 June 2015 at 11:35:43 UTC, weaselcat wrote:
ah yes, those famous fast C build times.
Excuse me while I go take half an hour to build GDB.
Heh... It is possible to write very fast C compilers with high
concurrency in builds, if there is a market for it, but most
people want
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
It is impossible for C++ to compile faster than D by design.
Any time it seems so you either aren't comparing same thing or
get misinformed. Or do straightforward separate compilation.
There are lots of features in D, that C++ does not
On 02/06/15 21:56, weaselcat wrote:
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer wrote:
My original statement was obviously exaggerated, I would not put up
with days-long compile times, I'd find another way to do development.
But compile time is not as important to me as it is
Project size is irrelevant here. I had 500 line C++ project that
took 10 minutes to compile (hello boost::spirit). It is
impossible for C++ to compile faster than D by design. Any time
it seems so you either aren't comparing same thing or get
misinformed. Or do straightforward separate
On Wednesday, 3 June 2015 at 09:21:55 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
It is impossible for C++ to compile faster than D by design.
Any time it seems so you either aren't comparing same thing or
get misinformed. Or do straightforward
On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:
it can get even better if you properly modularize your
projects instead of having 1-2 files that build slow, which
causes a lot of waiting.
Yes, sure. You can
On 6/3/15 3:50 AM, Paulo Pinto wrote:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
Project size is irrelevant here. I had 500 line C++ project that took
10 minutes to compile (hello boost::spirit). It is impossible for C++
to compile faster than D by design. Any time it seems so
On 6/3/15 10:19 AM, Paulo Pinto wrote:
On Wednesday, 3 June 2015 at 14:08:33 UTC, Steven Schveighoffer wrote:
On 6/3/15 3:50 AM, Paulo Pinto wrote:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
Project size is irrelevant here. I had 500 line C++ project that took
10 minutes to
On Wednesday, 3 June 2015 at 14:08:33 UTC, Steven Schveighoffer
wrote:
On 6/3/15 3:50 AM, Paulo Pinto wrote:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
Project size is irrelevant here. I had 500 line C++ project
that took
10 minutes to compile (hello boost::spirit). It is
On Wednesday, 3 June 2015 at 10:37:24 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 3 June 2015 at 07:50:53 UTC, Paulo Pinto wrote:
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
Project size is irrelevant here. I had 500 line C++ project
that took 10 minutes to compile (hello
On Wednesday, 3 June 2015 at 12:20:29 UTC, Paulo Pinto wrote:
Yes really, specially when comparing with Turbo Pascal, Delphi,
Modula-2, Oberon and a few other languages not tied to UNIX
linker model.
Yeah, I agree that the implementation for Turbo Pascal was good
for the hardware it ran on.
On 3 June 2015 at 13:35, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Grøstad wrote:
On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:
it can get even better if you properly modularize your projects instead
On Wednesday, 3 June 2015 at 15:14:47 UTC, Iain Buclaw wrote:
You're probably doing it wrong and accidentally building all of
binutils
instead. Use 'make all-gdb' and enjoy faster builds :-p
Or use TCC. :^P
On Wed, 03 Jun 2015 11:35:41 +, weaselcat wrote:
On Wednesday, 3 June 2015 at 11:25:50 UTC, Ola Fosheim Grøstad wrote:
On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:
it can get even better if you properly modularize your projects
instead of having 1-2 files that build slow,
On Wed, 03 Jun 2015 12:20:28 +, Paulo Pinto wrote:
Now really? C was designed at a time where you couldn't even hold the
source file in memory, so there is not even a need for an explicit AST.
C can essentially be streamed in separate passes:
cpp-cc-asm-linking
If compiling C is slow,
On 01/06/15 18:40, Steven Schveighoffer wrote:
On 5/30/15 2:38 PM, Shachar Shemesh wrote:
So given that a compiler actually *works* (i.e. produces valid
binaries), is speed of compilation better than speed of execution of the
resulting binary?
There is no answer to that question.
During
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer
wrote:
But if we are talking the difference between a compiler taking
10 minutes to produce a binary that is 20% faster than a
compiler that takes 1 minute, what is the threshold of pain you
are willing to accept? My preference is
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer
wrote:
My original statement was obviously exaggerated, I would not
put up with days-long compile times, I'd find another way to do
development. But compile time is not as important to me as it
is to others.
-Steve
I think if
On 2 June 2015 at 19:42, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 01/06/15 18:40, Steven Schveighoffer wrote:
On 5/30/15 2:38 PM, Shachar Shemesh wrote:
So given that a compiler actually *works* (i.e. produces valid
binaries), is speed of compilation better
On 1 Jun 2015 09:25, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote:
Got any bug reports to back that up? I should probably run the
testsuite with optimisations turned on sometime.
The latest one (the one that
On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote:
Got any bug reports to back that up? I should probably run the
testsuite with optimisations turned on sometime.
The latest one (the one that stung my code) is
http://bugzilla.gdcproject.org/show_bug.cgi?id=188. In general, the bugs
On 5/30/15 2:38 PM, Shachar Shemesh wrote:
On 30/05/15 03:57, Steven Schveighoffer wrote:
But I don't see how speed of compiler should sacrifice runtime
performance.
Our plan was to compile with DMD during the development stage, and then
switch to GDC for code intended for deployment. This
On 31/05/15 02:08, Manu via Digitalmars-d wrote:
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:
When he says Windows, he means MSVC, gcc backend will never support
interfacing that ABI (at
On 31 May 2015 at 17:59, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 31/05/15 02:08, Manu via Digitalmars-d wrote:
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:
On 30 May 2015 at 20:38, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 30/05/15 03:57, Steven Schveighoffer wrote:
I saw the slide from Liran that shows your compiler requirements :) I
can see why it's important to you.
Then you misunderstood Liran's slides.
On Saturday, 30 May 2015 at 17:00:18 UTC, Márcio Martins wrote:
Would clang's thread-sanitizer and address-sanitizer be
adaptable and usable with D as well?
these are already usable from LDC.
make sure you use the -gcc=clang flag.
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:
When he says Windows, he means MSVC, gcc backend will never support
interfacing that ABI (at least I see no motivation as of writing).
I thought that's what MINGW was. A gcc backend that interfaces with the
Windows ABI. Isn't it?
On 30 May 2015 19:05, via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Saturday, 30 May 2015 at 14:29:56 UTC, ketmar wrote:
On Sat, 30 May 2015 12:00:57 +, Kyoji Klyden wrote:
So personally I vote that speed optimizations on DMD are a waste of time
at the moment.
it's not only
On Saturday, 30 May 2015 at 14:29:56 UTC, ketmar wrote:
On Sat, 30 May 2015 12:00:57 +, Kyoji Klyden wrote:
So personally I vote that speed optimizations on DMD are a
waste of time
at the moment.
it's not only waste of time, it's unrealistic to make DMD
backend's
quality comparable to
On 30/05/15 03:57, Steven Schveighoffer wrote:
I saw the slide from Liran that shows your compiler requirements :) I
can see why it's important to you.
Then you misunderstood Liran's slides.
Our compile resources problem isn't with GDC. It's with DMD. Single
object compilation requires more
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:
When he says Windows, he means MSVC, gcc backend will never support
interfacing that ABI (at least I see no motivation as of writing).
I
On 30 May 2015 1:41 pm, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:
Both you and ketmer are evil.
I'm liking these ideas...
Now we just need some pretty and nice packages for e.g. Windows for ldc
with
On 30 May 2015 05:25, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, 30 May 2015 11:43:07 +1000, Manu via Digitalmars-d wrote:
* I don't mean to down-play GDC, but it can't give us Windows or iOS,
which are critical targets.
just to note: ARM is supported in GDC
On Friday, 29 May 2015 at 19:04:05 UTC, weaselcat wrote:
Maybe this should be brought up on LDC's issue tracker(that is,
slower compilation times compared to dmd.)
Although it might have already been discussed.
We are aware of this:
https://github.com/ldc-developers/ldc/issues/830
Regards,
On Friday, 29 May 2015 at 19:04:05 UTC, weaselcat wrote:
Not to mention that GDC and LDC benefit heavily from GCC and
LLVM respectively, these aren't exactly one man projects(e.g,
Google, Redhat, Intel, AMD etc contribute heavily to GCC and
LLVM is basically Apple's baby.)
Google, Intel,
Honestly I've never taken DMD to be the production compiler.
I've always left that to the GNU compilers. GDC has all the magic
and years of work with it's backend, so I'm not sure how dmd can
compare. As others of said, it's really the frontend that DMD is
providing that matters; once you have
On Sat, 30 May 2015 12:00:57 +, Kyoji Klyden wrote:
So personally I vote that speed optimizations on DMD are a waste of time
at the moment.
it's not only waste of time, it's unrealistic to make DMD backend's
quality comparable to GDC/LDC. it will require complete rewrite of backend
and
In nearly every benchmark I see D in, the default compiler used
is dmd which runs computationally intense tasks 4-5x+ slower than
GDC/LDC
example of a random blog post I found:
http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html
D is up to 10x(!) slower than Rust.
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
This will probably offend some people, but I think LDC/GDC
should be the
default download on dlang.org, and dmd should be provided as an
alternative for those who want the latest language version and
don't
mind the speed compromise.
On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d
wrote:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
This will probably offend some people, but I think LDC/GDC should be
the default
On Fri, 29 May 2015 23:29:39 +, weaselcat wrote:
On Friday, 29 May 2015 at 23:19:36 UTC, ketmar wrote:
On Fri, 29 May 2015 20:02:47 +, Martin Krejcirik wrote:
dmd
- reference compiler, Digital Mars backend - best for
latest dlang
features, fast compile times
gdc
- GNU
On Fri, 29 May 2015 20:02:47 +, Martin Krejcirik wrote:
dmd
- reference compiler, Digital Mars backend - best for latest dlang
features, fast compile times
gdc
- GNU gcc backend based compiler - best for portability and
compatibility with gnu tools
ldc
- LLVM
On Friday, 29 May 2015 at 19:16:45 UTC, Steven Schveighoffer
wrote:
On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via
Digitalmars-d wrote:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
This will probably offend some
On Friday, 29 May 2015 at 23:19:36 UTC, ketmar wrote:
On Fri, 29 May 2015 20:02:47 +, Martin Krejcirik wrote:
dmd
- reference compiler, Digital Mars backend - best for
latest dlang
features, fast compile times
gdc
- GNU gcc backend based compiler - best for portability and
On Friday, 29 May 2015 at 22:05:27 UTC, Idan Arye wrote:
For the development cycle too?
I've had LDC edge out dmd in compilation times during development
cycle. dmd sees zero boost from separate object compilation.
Using DCD as an example(because it has not-long not-short build
times,)
On 5/29/15 4:05 PM, Idan Arye wrote:
On Friday, 29 May 2015 at 19:16:45 UTC, Steven Schveighoffer wrote:
On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d
wrote:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh
On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:
Both you and ketmer are evil.
I'm liking these ideas...
Now we just need some pretty and nice packages for e.g. Windows
for ldc with debugger full support and we will be good.
Last time I looked llvm still needs a lot of work
On 30/05/2015 3:36 p.m., weaselcat wrote:
On Saturday, 30 May 2015 at 03:24:45 UTC, Rikki Cattermole wrote:
Both you and ketmer are evil.
I'm liking these ideas...
Now we just need some pretty and nice packages for e.g. Windows for
ldc with debugger full support and we will be good.
Last time
On 30 May 2015 at 09:14, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d
wrote:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
On Saturday, 30 May 2015 at 04:01:00 UTC, Manu wrote:
I'm having a pretty good experience with win64 ldc lately.
Obviously the
fact that there's no debug info is a gigantic hole.
I have a hack environment where I dmd in debug and ldc for
release builds,
but it's really not ideal. And you're
I'm having a pretty good experience with win64 ldc lately. Obviously the
fact that there's no debug info is a gigantic hole.
I have a hack environment where I dmd in debug and ldc for release builds,
but it's really not ideal. And you're limited to code that doesn't expose
bugs in both compilers.
On 30/05/2015 1:43 p.m., Manu via Digitalmars-d wrote:
On 30 May 2015 at 09:14, ketmar via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Fri, 29 May 2015 11:58:09 -0700, H. S. Teoh via Digitalmars-d wrote:
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d
wrote:
On
On Sat, 30 May 2015 11:43:07 +1000, Manu via Digitalmars-d wrote:
* I don't mean to down-play GDC, but it can't give us Windows or iOS,
which are critical targets.
just to note: ARM is supported in GDC (althru i never tested that support
myself), and there are semi-official windows builds of
On Fri, May 29, 2015 at 06:13:02PM +, weaselcat via Digitalmars-d wrote:
In nearly every benchmark I see D in, the default compiler used is dmd
which runs computationally intense tasks 4-5x+ slower than GDC/LDC
As I keep saying, in my own compute-intensive projects I have
consistently found
On Friday, 29 May 2015 at 19:01:18 UTC, H. S. Teoh wrote:
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via
Digitalmars-d wrote:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
This will probably offend some people, but I think LDC/GDC
should be
the default download on dlang.org,
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d wrote:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
This will probably offend some people, but I think LDC/GDC should be
the default download on dlang.org, and dmd should be provided as an
alternative for those
On 5/29/15 12:13 PM, weaselcat wrote:
In nearly every benchmark I see D in, the default compiler used is dmd
which runs computationally intense tasks 4-5x+ slower than GDC/LDC
example of a random blog post I found:
http://vaskir.blogspot.com/2015/04/computing-cryptography-hashes-rust-vs-f.html
On 5/29/15 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, May 29, 2015 at 06:50:02PM +, Dicebot via Digitalmars-d wrote:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
This will probably offend some people, but I think LDC/GDC should be
the default download on dlang.org,
On Friday, 29 May 2015 at 20:23:13 UTC, Vladimir Panteleev wrote:
On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu
wrote:
On 5/29/15 12:13 PM, weaselcat wrote:
In nearly every benchmark I see D in, the default compiler
used is dmd
which runs computationally intense tasks 4-5x+
On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote:
Note to benchmark users: please use ldc compiler with -inline
-O -boundscheck=off (or whatever is correct for LDC) options
for best results
AFAIK you shouldn't use the -inline flag with LDC, as it tells
LDC to run the inline
IMHO all what is needed is to update the download page with some
description of deferences between the compilers, like:
dmd
- reference compiler, Digital Mars backend
- best for latest dlang features, fast compile times
gdc
- GNU gcc backend based compiler
- best for portability and
On Friday, 29 May 2015 at 20:02:49 UTC, Martin Krejcirik wrote:
IMHO all what is needed is to update the download page with
some description of deferences between the compilers, like:
+1
On 29 May 2015 20:15, weaselcat via Digitalmars-d
digitalmars-d@puremagic.com wrote:
In nearly every benchmark I see D in, the default compiler used is dmd
which runs computationally intense tasks 4-5x+ slower than GDC/LDC
example of a random blog post I found:
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
On Fri, May 29, 2015 at 06:13:02PM +, weaselcat via
Digitalmars-d wrote:
In nearly every benchmark I see D in, the default compiler
used is dmd
which runs computationally intense tasks 4-5x+ slower than
GDC/LDC
As I keep saying,
On Friday, 29 May 2015 at 18:38:20 UTC, H. S. Teoh wrote:
On Fri, May 29, 2015 at 06:13:02PM +, weaselcat via
Digitalmars-d wrote:
In nearly every benchmark I see D in, the default compiler
used is dmd
which runs computationally intense tasks 4-5x+ slower than
GDC/LDC
As I keep saying,
On Friday, 29 May 2015 at 19:17:14 UTC, Andrei Alexandrescu wrote:
On 5/29/15 12:13 PM, weaselcat wrote:
In nearly every benchmark I see D in, the default compiler
used is dmd
which runs computationally intense tasks 4-5x+ slower than
GDC/LDC
example of a random blog post I found:
79 matches
Mail list logo
