On 05/06/2015 23:07, Iain Buclaw via Digitalmars-d wrote:
On 5 Jun 2015 20:55, "Bruno Medeiros via Digitalmars-d"
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 this, in basica
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 v
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
>f
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 comm
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 "nativ
On 2015-06-03 12:37, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" 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 compil
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 sep
ketmar 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 editor, compiler, and l
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 buil
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 co
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 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
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 comp
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 impossi
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 you
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 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 boost
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 som
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 prob
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
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 eno
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 sepa
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. A
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 design
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 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 o
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 compilat
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 to
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 comp
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 for
On 2 June 2015 at 19:42, Shachar Shemesh via Digitalmars-d
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 than speed of execut
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 develo
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 pl
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 on
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
o
On 31 May 2015 at 10:45, Manu via Digitalmars-d wrote:
> On 31 May 2015 at 17:59, Shachar Shemesh via Digitalmars-d
> wrote:
> > On 31/05/15 02:08, Manu via Digitalmars-d wrote:
> >>
> >> On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
> >> wrote:
> >>>
> >>> On 30/05/15 11:00, Iain
On 31 May 2015 at 17:59, Shachar Shemesh via Digitalmars-d
wrote:
> On 31/05/15 02:08, Manu via Digitalmars-d wrote:
>>
>> On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
>> wrote:
>>>
>>> On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:
When he says Windows,
On 31/05/15 02:08, Manu via Digitalmars-d wrote:
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
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
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
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 thought that's what
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 s
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?
Shacha
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 30 May 2015 19:05, "via Digitalmars-d"
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 waste
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 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 G
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
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 hav
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, AMD,
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
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
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 li
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 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 fo
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/05/2015 1:43 p.m., Manu via Digitalmars-d wrote:
On 30 May 2015 at 09:14, ketmar via Digitalmars-d
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:2
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 30 May 2015 at 09:14, ketmar via Digitalmars-d
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:
>>> >This will probabl
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 wrote:
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
>
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
co
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
>- LL
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 defau
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,)
i
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 people
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 LLVM
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+ slower
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:
http://vaski
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
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 com
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, a
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.or
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, in
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, in
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:
>
http://vaskir.blogspot
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 th
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.
I
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 foun
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.
80 matches
Mail list logo