On Tuesday, 18 August 2015 at 17:10:36 UTC, Vladimir Panteleev
wrote:
On Tuesday, 18 August 2015 at 12:37:37 UTC, Vladimir Panteleev
wrote:
I suggest that we revamp the compiler download page again. The
lead should be a select your compiler which lists the
advantages and disadvantages of each
On Sun, Aug 23, 2015 at 12:03:25AM +, Vladimir Panteleev via Digitalmars-d
wrote:
On Tuesday, 18 August 2015 at 17:10:36 UTC, Vladimir Panteleev wrote:
On Tuesday, 18 August 2015 at 12:37:37 UTC, Vladimir Panteleev wrote:
I suggest that we revamp the compiler download page again. The lead
On Sun, Aug 23, 2015 at 12:03:25AM +, Vladimir Panteleev via Digitalmars-d
wrote:
On Tuesday, 18 August 2015 at 17:10:36 UTC, Vladimir Panteleev wrote:
On Tuesday, 18 August 2015 at 12:37:37 UTC, Vladimir Panteleev wrote:
I suggest that we revamp the compiler download page again. The lead
On Fri, Aug 21, 2015 at 07:17:03PM -0700, Walter Bright via Digitalmars-d wrote:
On 8/19/2015 10:25 AM, deadalnix wrote:
Replicating a scalar SSA like LLVM does not make a lot of sense.
What would make a lot of sense would be to start work on an
experimental SIMD SSA implemented in D that
On Saturday, 22 August 2015 at 02:17:04 UTC, Walter Bright wrote:
On 8/19/2015 10:25 AM, deadalnix wrote:
Replicating a scalar SSA like LLVM does not make a lot of
sense. What would
make a lot of sense would be to start work on an experimental
SIMD SSA
implemented in D that could leverage
On Friday, 21 August 2015 at 02:02:57 UTC, rsw0x wrote:
On Friday, 21 August 2015 at 01:20:27 UTC, jmh530 wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc version, by contrast, inlines *everything*,
This could be why I've observed performance differentials in
dmd
On Friday, 21 August 2015 at 01:29:12 UTC, H. S. Teoh wrote:
On Fri, Aug 21, 2015 at 01:20:25AM +, jmh530 via
Digitalmars-d wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc version, by contrast, inlines *everything*,
This could be why I've observed performance
On Fri, Aug 21, 2015 at 03:09:42PM +, Ivan Kazmenko via Digitalmars-d wrote:
On Friday, 21 August 2015 at 01:29:12 UTC, H. S. Teoh wrote:
On Fri, Aug 21, 2015 at 01:20:25AM +, jmh530 via Digitalmars-d wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc
On Friday, 21 August 2015 at 20:47:36 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 21 August 2015 at 20:41:58 UTC, deadalnix wrote:
On Friday, 21 August 2015 at 10:11:52 UTC, Ola Fosheim Grøstad
wrote:
Replicating a scalar SSA like LLVM does not make a lot of
sense. What would make a lot of
On Friday, 21 August 2015 at 10:11:52 UTC, Ola Fosheim Grøstad
wrote:
Replicating a scalar SSA like LLVM does not make a lot of
sense. What would make a lot of sense would be to start work
WAT ?
When simplifying over scalars you make a trade off. By having a
simplifier that is optimized
On Friday, 21 August 2015 at 20:41:58 UTC, deadalnix wrote:
On Friday, 21 August 2015 at 10:11:52 UTC, Ola Fosheim Grøstad
wrote:
Replicating a scalar SSA like LLVM does not make a lot of
sense. What would make a lot of sense would be to start work
WAT ?
When simplifying over scalars you
On Friday, 21 August 2015 at 21:04:08 UTC, deadalnix wrote:
The answer is blue. KAMOULOX !
You need to change your attitude.
On 8/19/2015 10:25 AM, deadalnix wrote:
Replicating a scalar SSA like LLVM does not make a lot of sense. What would
make a lot of sense would be to start work on an experimental SIMD SSA
implemented in D that could leverage benefits for next gen x86 SIMD and make
Phobos target it. That could
On Friday, 21 August 2015 at 01:29:12 UTC, H. S. Teoh wrote:
Have you tried using gdc -O3 (or ldc) to see if there's a big
difference?
How -Os and -march=native change the picture?
On 21 August 2015 at 10:49, Kagamin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 21 August 2015 at 01:29:12 UTC, H. S. Teoh wrote:
Have you tried using gdc -O3 (or ldc) to see if there's a big
difference?
How -Os and -march=native change the picture?
There's a paper
On Friday, 21 August 2015 at 09:17:28 UTC, Iain Buclaw wrote:
There's a paper somewhere about optimisations on Intel
processors that says that -O2 produces overall better results
than -O3 (I'll have to dig it out).
That being said, recently I compared performance of the datetime
library
On Wednesday, 19 August 2015 at 17:25:13 UTC, deadalnix wrote:
Apple is invested in LLVM. For other thing you mention,
WebAssembly is an AST representation, which is both dumb and do
not look like anything like LLVM IR.
For the time being asm.js is a starting point. Nobody knows what
On 2015-08-19 20:41, Walter Bright wrote:
It's true that if generating an exe, the compiler can mark leaf classes
as final and get devirtualization.
Since D has the override keyword it should be possible to devirtualize
a call to a non leaf classes as well, as long as the method is not
On Friday, 21 August 2015 at 01:20:27 UTC, jmh530 wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc version, by contrast, inlines *everything*,
This could be why I've observed performance differentials in
dmd for doing some manual for loops rather than using the
On 8/20/2015 6:06 PM, H. S. Teoh via Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=14943
Thanks!
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc version, by contrast, inlines *everything*,
This could be why I've observed performance differentials in dmd
for doing some manual for loops rather than using the stuff in
std.algorithms.
On 8/20/2015 4:56 PM, H. S. Teoh via Digitalmars-d wrote:
I didn't include the assembly listings, as it's rather long, but if
people are interested I'll trim them down to the parts of interest and
post them in a follow-up post.
Thank you. This belongs as an enhancement request in bugzilla,
On Fri, Aug 21, 2015 at 01:20:25AM +, jmh530 via Digitalmars-d wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc version, by contrast, inlines *everything*,
This could be why I've observed performance differentials in dmd for
doing some manual for loops rather
On Tue, Aug 18, 2015 at 04:30:26PM -0700, Walter Bright via Digitalmars-d wrote:
On 8/18/2015 4:05 PM, H. S. Teoh via Digitalmars-d wrote:
Maybe when I get some free time this week, I could look at the
disassembly of one of my programs again to give some specific
examples.
Please do.
On Thu, Aug 20, 2015 at 05:30:25PM -0700, Walter Bright via Digitalmars-d wrote:
On 8/20/2015 4:56 PM, H. S. Teoh via Digitalmars-d wrote:
I didn't include the assembly listings, as it's rather long, but if
people are interested I'll trim them down to the parts of interest
and post them in a
On Wednesday, 19 August 2015 at 10:50:24 UTC, Ola Fosheim Grøstad
wrote:
Well… I can't argue with what you find interesting. Memory
throughput and pipeline bubbles are the key bottlenecks these
days.
And just to stress this point: if you code is spending 50% of the
time waiting for memory
On 18-Aug-2015 15:37, Vladimir Panteleev wrote:
I think stability of the DMD backend is a goal of much higher value than
the performance of the code it emits. DMD is never going to match the
code generation quality of LLVM and GCC, which have had many, many
man-years invested in them. Working on
On 19-Aug-2015 15:53, Jacob Carlborg wrote:
On 2015-08-19 00:55, Walter Bright wrote:
Exactly. That's why people just want to type -O and it optimizes.
So why not just -pgo that does that you described above?
+1 for -pgo to use trace.log in the same folder that way running
-profile
On 2015-08-19 15:00, Dmitry Olshansky wrote:
+1 for -pgo to use trace.log in the same folder that way running
-profile folowed by -pgo will just work (tm).
I was thinking something the compiler would handle everything
automatically in one command with the -pgo flag present. If necessary,
On 2015-08-19 00:55, Walter Bright wrote:
Exactly. That's why people just want to type -O and it optimizes.
So why not just -pgo that does that you described above?
--
/Jacob Carlborg
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
So if you're comparing code generated by dmd/gdc/ldc, and
notice something that dmd could do better at (1, 2 or 3),
please let me know. Often this sort of thing is low hanging
fruit that is fairly easily inserted into the back
On 18 August 2015 at 12:45, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Martin ran some benchmarks recently that showed that ddmd compiled with
dmd was about 30% slower than when compiled with gdc/ldc. This seems to be
fairly typical.
I'm interested in ways to reduce
On 8/19/2015 7:34 AM, anonymous wrote:
I have a about 30 lines of numerical code (using real) where the gap is about
200%-300% between ldc/gdc and dmd (linux x86_64). In fact dmd -O etc is at the
level of ldc/gdc without any optimizations and dmd without -0 is even slower.
With double instead of
On 8/19/2015 9:53 AM, Iain Buclaw via Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=14936
(Consider this my contribution to your low hanging fruit)
Thanks!
On Wednesday, 19 August 2015 at 17:25:13 UTC, deadalnix wrote:
Apple is invested in LLVM. For other thing you mention,
WebAssembly is an AST representation, which is both dumb and do
not look like anything like LLVM IR.
I saw more similarity between wasm and SPIR-V than LLVM, but it
On 2015-08-18 12:45, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd compiled with
dmd was about 30% slower than when compiled with gdc/ldc. This seems to
be fairly typical.
Not sure how the compilers behave in this case but what about
devirtualization? Since I
On Wednesday, 19 August 2015 at 09:26:43 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 19 August 2015 at 08:22:58 UTC, Dmitry Olshansky
wrote:
Also DMD's backend strives to stay fast _and_ generate fine
machine code. Getting within 10% of GCC/LLVM and being fast is
IMHO both possible and
On 2015-08-18 23:43, Walter Bright wrote:
I wonder how many people actually use the llvm profile guided
optimizations. I suspect very, very few.
In Xcode there's a checkbox for PGO in the build configuration. Should
be just as easy to enable as any other build setting.
--
/Jacob Carlborg
On Wednesday, 19 August 2015 at 18:41:07 UTC, Walter Bright wrote:
On 8/19/2015 11:03 AM, Jacob Carlborg wrote:
Not sure how the compilers behave in this case but what about
devirtualization?
Since I think most developers compile their D programs with
all files at once
there should be pretty
On 8/19/2015 11:03 AM, Jacob Carlborg wrote:
Not sure how the compilers behave in this case but what about devirtualization?
Since I think most developers compile their D programs with all files at once
there should be pretty good opportunities to do devirtualization.
It's true that if
On Wednesday, 19 August 2015 at 18:26:45 UTC, jmh530 wrote:
On Wednesday, 19 August 2015 at 17:25:13 UTC, deadalnix wrote:
Apple is invested in LLVM. For other thing you mention,
WebAssembly is an AST representation, which is both dumb and
do not look like anything like LLVM IR.
I saw more
On Wednesday, 19 August 2015 at 17:30:13 UTC, Walter Bright wrote:
On 8/19/2015 7:34 AM, anonymous wrote:
I have a about 30 lines of numerical code (using real) where
the gap is about
200%-300% between ldc/gdc and dmd (linux x86_64). In fact dmd
-O etc is at the
level of ldc/gdc without any
On Wednesday, 19 August 2015 at 18:47:21 UTC, Paulo Pinto wrote:
On Wednesday, 19 August 2015 at 18:41:07 UTC, Walter Bright
wrote:
On 8/19/2015 11:03 AM, Jacob Carlborg wrote:
Not sure how the compilers behave in this case but what about
devirtualization?
Since I think most developers compile
On 19 August 2015 at 21:00, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 19 August 2015 at 18:47:21 UTC, Paulo Pinto wrote:
On Wednesday, 19 August 2015 at 18:41:07 UTC, Walter Bright wrote:
On 8/19/2015 11:03 AM, Jacob Carlborg wrote:
Not sure how the
On Wednesday, 19 August 2015 at 11:22:09 UTC, Dmitry Olshansky
wrote:
On 18-Aug-2015 15:37, Vladimir Panteleev wrote:
I think stability of the DMD backend is a goal of much higher
value than
the performance of the code it emits. DMD is never going to
match the
code generation quality of LLVM
On 8/19/2015 12:39 PM, anonymous wrote:
The problem are not the 30 lines + white space but the input file used in my
benchmark. The whole benchmark programm has 115 lines including empty lines and
braces. The input file is 4.8 MB large.
Anyway the raw asm generated by the different compiler may
On 08/18/2015 12:45 PM, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd compiled with
dmd was about 30% slower than when compiled with gdc/ldc. This seems to
be fairly typical.
I'm interested in ways to reduce that gap.
There are 3 broad kinds of optimizations
On Wednesday, 19 August 2015 at 20:54:39 UTC, qznc wrote:
On Wednesday, 19 August 2015 at 11:22:09 UTC, Dmitry Olshansky
wrote:
On 18-Aug-2015 15:37, Vladimir Panteleev wrote:
[...]
How about stress-testing with some simple fuzzer:
1. Generate a sequence of pluasable expressions/functions.
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd
compiled with dmd was about 30% slower than when compiled with
gdc/ldc. This seems to be fairly typical.
I'm interested in ways to reduce that gap.
There are 3 broad
On Wednesday, 19 August 2015 at 22:58:35 UTC, Timon Gehr wrote:
Maybe relevant: There's some work on automatically discovering
peephole optimizations that a compiler misses, e.g.
http://blog.regehr.org/archives/1109
There is a talk of this
https://www.youtube.com/watch?v=Ux0YnVEaI6A
On Tuesday, 18 August 2015 at 22:55:06 UTC, Walter Bright wrote:
On 8/18/2015 3:17 PM, welkam wrote:
People are lazy and if it takes more than one click people
wont use it. Just
like unitesting everyone agrees that its good to write them
but nobody does
that. When you put unitesting in
On Wednesday, 19 August 2015 at 10:16:18 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 19 August 2015 at 10:08:48 UTC, ponce wrote:
Even in video codec, AVX2 is not that useful and barely brings
a 10% improvements over SSE, while being extra careful with
SSE-AVX transition penalty. And to reap
On 19-Aug-2015 13:09, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 19 August 2015 at 09:55:19 UTC, Dmitry Olshansky wrote:
On 19-Aug-2015 12:46, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
Well, you can start
On Wednesday, 19 August 2015 at 10:25:14 UTC, ponce wrote:
Loops in video coding already have no conditional. And for the
one who have, conditionals were already removeable with
existing instructions.
I think you are side-stepping the issue. Most people don't write
video codecs. Most people
On Wednesday, 19 August 2015 at 10:33:40 UTC, Dmitry Olshansky
wrote:
Given how flexble the current data types are I hardly see it
implemented in a sane way not to mention benefits could
berather slim. Lastly - why the omnipotnent (by this thread)
LLVM/GCC guys won't implement it yet?
They
On Tuesday, 18 August 2015 at 12:58:45 UTC, Dicebot wrote:
On Tuesday, 18 August 2015 at 12:37:37 UTC, Vladimir Panteleev
wrote:
I think stability of the DMD backend is a goal of much higher
value than the performance of the code it emits. DMD is never
going to match the code generation
On Wednesday, 19 August 2015 at 10:08:48 UTC, ponce wrote:
Even in video codec, AVX2 is not that useful and barely brings
a 10% improvements over SSE, while being extra careful with
SSE-AVX transition penalty. And to reap this benefit you would
have to write in intrinsics/assembly.
Masked
On Wednesday, 19 August 2015 at 09:29:31 UTC, Dmitry Olshansky
wrote:
I do not. I underestime the benefits of tons of subtle passes
that play into 0.1-0.2% in some cases. There are lots and lots
of this in GCC/LLVM. If having the best code generated out
there is not the goal we can safely omit
On 19-Aug-2015 12:46, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 19 August 2015 at 09:29:31 UTC, Dmitry Olshansky wrote:
I do not. I underestime the benefits of tons of subtle passes that
play into 0.1-0.2% in some cases. There are lots and
On Wednesday, 19 August 2015 at 09:55:19 UTC, Dmitry Olshansky
wrote:
On 19-Aug-2015 12:46, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
Well, you can start on this now, but by the time it is ready
and
hardened, LLVM might have received improved AVX2 and
On Wednesday, 19 August 2015 at 09:55:19 UTC, Dmitry Olshansky
wrote:
On 19-Aug-2015 12:46, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 19 August 2015 at 09:29:31 UTC, Dmitry Olshansky
wrote:
I do not. I underestime the benefits of tons of
On 19-Aug-2015 00:34, H. S. Teoh via Digitalmars-d wrote:
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd compiled
with dmd was about 30% slower than when compiled with gdc/ldc. This
seems to be fairly typical.
[...]
On Wednesday, 19 August 2015 at 08:29:05 UTC, Walter Bright wrote:
On 8/19/2015 1:11 AM, Dmitry Olshansky wrote:
When looking at AST there is no way to correctly estimate cost
function - code
generated may be huge with user-defined types/operators.
Sure the cost function is fuzzy, but it
On 19-Aug-2015 12:26, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
And there is plenty of research papers on optimization floating around
and implemented in GCC/LLVM/MSVC so most of RD cost is payed by other
backends/researchers.
I think you underestimate the
On Wednesday, 19 August 2015 at 08:22:58 UTC, Dmitry Olshansky
wrote:
Also DMD's backend strives to stay fast _and_ generate fine
machine code. Getting within 10% of GCC/LLVM and being fast is
IMHO both possible and should be done.
But if iOS/OS-X and others are essentially requiring an
On 8/19/2015 1:11 AM, Dmitry Olshansky wrote:
When looking at AST there is no way to correctly estimate cost function - code
generated may be huge with user-defined types/operators.
Sure the cost function is fuzzy, but it tends to work well enough.
On 19-Aug-2015 00:43, Walter Bright wrote:
On 8/18/2015 1:33 PM, Jacob Carlborg wrote:
There's profile guided optimization, which LLVM supports.
dmd does have that to some extent. If you run with -profile, the
profiler will emit a trace.def file. This is a script which can be fed
to the
On 19-Aug-2015 01:14, Walter Bright wrote:
On 8/18/2015 3:04 PM, deadalnix wrote:
My understanding is that the inliner is in the front end. This
definitively do
not work the way I describe it here.
But it uses a cost function and runs repeatedly until there is no more
inlining to be done.
Martin ran some benchmarks recently that showed that ddmd compiled with dmd was
about 30% slower than when compiled with gdc/ldc. This seems to be fairly typical.
I'm interested in ways to reduce that gap.
There are 3 broad kinds of optimizations that compilers do:
1. source translations like
On Tuesday, 18 August 2015 at 12:37:37 UTC, Vladimir Panteleev
wrote:
I think stability of the DMD backend is a goal of much higher
value than the performance of the code it emits. DMD is never
going to match the code generation quality of LLVM and GCC,
which have had many, many man-years
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd
compiled with dmd was about 30% slower than when compiled with
gdc/ldc. This seems to be fairly typical.
I'm interested in ways to reduce that gap.
There are 3 broad
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
So if you're comparing code generated by dmd/gdc/ldc, and
notice something that dmd could do better at (1, 2 or 3),
please let me know. Often this sort of thing is low hanging
fruit that is fairly easily inserted into the back
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
So if you're comparing code generated by dmd/gdc/ldc, and
notice something that dmd could do better at (1, 2 or 3),
please let me know. Often this sort of thing is low hanging
fruit that is fairly easily inserted into the back
On Tuesday, 18 August 2015 at 12:32:17 UTC, Etienne Cimon wrote:
a crypto library that you can't optimize, building -O -g also
gives me a ccog.c ICE error. I think it might be something
about `asm pure` that uses some locals, does that eliminate the
function call parameters?
Sorry that was
On 2015-08-18 17:22, Joakim wrote:
Well, you have to admit that it's pretty impressive that dmd's backend
gets within 30% of those monumental backends despite having pretty much
only Walter working on it sporadically.
DMD has only a very limited set of targets compared to LLVM and GCC. So
On 8/18/2015 5:37 AM, Vladimir Panteleev wrote:
IIRC, I have had three releases affected by optimization/inlining DMD bugs (two
of Digger and one of RABCDAsm). These do not speak well for D when end-users ask
me what the cause of the bug is, and I have to say Yeah, it's a bug in the
official D
On Tuesday, 18 August 2015 at 12:37:37 UTC, Vladimir Panteleev
wrote:
I suggest that we revamp the compiler download page again. The
lead should be a select your compiler which lists the
advantages and disadvantages of each of DMD, LDC and GDC.
Soon ? Are you sure ?
Some people said that 2.068 frontend will be in D.
And it's not.
I think it's a really bad idea to optimize dmd's backend.
It will add new regressions and it will make it more complex and
slower.
I think it's better to fix bugs and not to optimize that backend.
On 8/18/2015 5:32 AM, Etienne Cimon wrote:
Other than that, there was a recent Java vs D thread which showed it orders of
magnitude faster on vtable calls. So I think the most amazing feature would be
to allow profiling sampling to compile with samples and select which functions
to inline or do
On 18/08/15 12:45, Walter Bright via Digitalmars-d wrote:
Martin ran some benchmarks recently that showed that ddmd compiled with dmd was
about 30% slower than when compiled with gdc/ldc. This seems to be fairly
typical.
I'm interested in ways to reduce that gap.
All things considered,
On Tuesday, 18 August 2015 at 20:28:48 UTC, Walter Bright wrote:
On 8/18/2015 12:38 PM, deadalnix wrote:
And honestly, there is no way DMD can catch up.
I find your lack of faith disturbing.
https://www.youtube.com/watch?v=Zzs-OvfG8tEfeature=player_detailpage#t=91
Let's say I have some
On Tuesday, 18 August 2015 at 21:18:34 UTC, rsw0x wrote:
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd
compiled with dmd was about 30% slower than when compiled with
gdc/ldc. This seems to be fairly typical.
I'm
On Tuesday, 18 August 2015 at 20:24:31 UTC, Vladimir Panteleev
wrote:
On Tuesday, 18 August 2015 at 19:02:20 UTC, Walter Bright wrote:
On 8/18/2015 5:37 AM, Vladimir Panteleev wrote:
IIRC, I have had three releases affected by
optimization/inlining DMD bugs (two
of Digger and one of RABCDAsm).
On 8/18/2015 1:47 PM, deadalnix wrote:
Realistically, D does not have the man power required to reach the same level of
optimization, and have many higher impact task to spend that manpower on.
dmd also does a sludge of patterns. I'm just looking for a few that would
significantly impact the
On 8/18/2015 2:26 PM, rsw0x wrote:
if you want to make D fast - Fix the interface between the compiler and the
runtime(including the inability for compilers to inline simple things like
allocations which makes allocations have massive overheads.) Then, fix the GC.
Make the GC both shared and
On Tuesday, 18 August 2015 at 21:36:39 UTC, Walter Bright wrote:
On 8/18/2015 2:26 PM, rsw0x wrote:
if you want to make D fast - Fix the interface between the
compiler and the
runtime(including the inability for compilers to inline simple
things like
allocations which makes allocations have
On 18 August 2015 at 23:25, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/18/2015 1:47 PM, deadalnix wrote:
Realistically, D does not have the man power required to reach the same
level of
optimization, and have many higher impact task to spend that manpower on.
On Tuesday, 18 August 2015 at 21:43:44 UTC, Walter Bright wrote:
On 8/18/2015 1:33 PM, Jacob Carlborg wrote:
There's profile guided optimization, which LLVM supports.
dmd does have that to some extent. If you run with -profile,
the profiler will emit a trace.def file. This is a script which
On Tuesday, 18 August 2015 at 22:14:52 UTC, Walter Bright wrote:
On 8/18/2015 3:04 PM, deadalnix wrote:
My understanding is that the inliner is in the front end. This
definitively do
not work the way I describe it here.
But it uses a cost function and runs repeatedly until there is
no more
On Tuesday, 18 August 2015 at 17:31:50 UTC, Jacob Carlborg wrote:
On 2015-08-18 17:22, Joakim wrote:
Well, you have to admit that it's pretty impressive that dmd's
backend
gets within 30% of those monumental backends despite having
pretty much
only Walter working on it sporadically.
DMD
On Tue, Aug 18, 2015 at 07:38:43PM +, deadalnix via Digitalmars-d wrote:
On Tuesday, 18 August 2015 at 17:31:50 UTC, Jacob Carlborg wrote:
On 2015-08-18 17:22, Joakim wrote:
Well, you have to admit that it's pretty impressive that dmd's
backend gets within 30% of those monumental
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd compiled
with dmd was about 30% slower than when compiled with gdc/ldc. This
seems to be fairly typical.
[...]
This matches my experience of dmd vs. gdc as well. No
On Tuesday, 18 August 2015 at 21:45:42 UTC, rsw0x wrote:
If you want D to have a GC, you have to design the language
around having a GC. Right now, D could be likened to using C++
with Boehm.
The irony is that most GC-related complaints are the exact
opposite - that the language depends too
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote:
Martin ran some benchmarks recently that showed that ddmd
compiled with dmd was about 30% slower than when compiled with
gdc/ldc. This seems to be fairly typical.
I'm interested in ways to reduce that gap.
retire dmd?
this is
On 8/18/2015 1:33 PM, Jacob Carlborg wrote:
There's profile guided optimization, which LLVM supports.
dmd does have that to some extent. If you run with -profile, the profiler will
emit a trace.def file. This is a script which can be fed to the linker which
controls the layout of functions
On Tuesday, 18 August 2015 at 21:58:58 UTC, Walter Bright wrote:
On 8/18/2015 2:32 PM, Joseph Rushton Wakeling wrote:
However true that may be in general, those almost certainly
aren't the reasons
why ddmd benchmarks 30% slower than dmd. I would suspect that
particular speed
difference is
On 8/18/2015 3:04 PM, deadalnix wrote:
My understanding is that the inliner is in the front end. This definitively do
not work the way I describe it here.
But it uses a cost function and runs repeatedly until there is no more inlining
to be done.
It stand for 'scalar replacement of
On 8/18/2015 12:38 PM, deadalnix wrote:
And honestly, there is no way DMD can catch up.
I find your lack of faith disturbing.
https://www.youtube.com/watch?v=Zzs-OvfG8tEfeature=player_detailpage#t=91
On Tuesday, 18 August 2015 at 21:41:26 UTC, deadalnix wrote:
On Tuesday, 18 August 2015 at 21:26:43 UTC, rsw0x wrote:
On Tuesday, 18 August 2015 at 21:18:34 UTC, rsw0x wrote:
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright
wrote:
Martin ran some benchmarks recently that showed that
On Tuesday, 18 August 2015 at 21:31:17 UTC, Walter Bright wrote:
On 8/18/2015 1:24 PM, Vladimir Panteleev wrote:
The specific bugs in question have
been fixed, but that doesn't change the general problem.
The reason we have regression tests is to make sure things that
are fixed stay fixed.
201 - 300 of 329 matches
Mail list logo
