On Tuesday, 7 April 2015 at 08:25:02 UTC, Dicebot wrote:
See, the problem with this approach is that you can trivially
get out of 1GB of memory with DMD even when compiling single
module, all you need is to do enough compile-time magic.
Separate compilation here delays the issue but does not
a
On Tuesday, 7 April 2015 at 08:28:08 UTC, Dicebot wrote:
And I have never been speaking about "normal WPO", only about
one specific to D semantics.
AFAIK, hypothetical D-specific optimizations were never
implemented (like elision of pure calls and optimization of
immutable data). But they wor
On Monday, 6 April 2015 at 11:29:20 UTC, Sergei Nosov wrote:
On Sunday, 5 April 2015 at 00:22:35 UTC, Atila Neves wrote:
It seems to me that different projects might benefit from
different compilation strategies. It might just be a case of
unit tests alongside production code vs in separate fil
On Sunday, 5 April 2015 at 12:50:52 UTC, Kagamin wrote:
On Sunday, 5 April 2015 at 12:22:15 UTC, Dicebot wrote:
Unless LDC does some D specific WPO magic I am not aware of
this is not what your original statement was about.
llvm does normal WPO in a sense that compiled code is not
opaque.
A
On Sunday, 5 April 2015 at 00:22:35 UTC, Atila Neves wrote:
It seems to me that different projects might benefit from
different compilation strategies. It might just be a case of
unit tests alongside production code vs in separate files. As
mentioned before, my experience with per-module compil
On 4/4/15 12:56 PM, Dicebot wrote:
Even if you consistently work with the same project it is incredibly
rare to have a changeset contained in a single module. And if there are
at least 5 changed modules (including inter-dependencies) it becomes
long enough already.
That's my experience as well
On Sunday, 5 April 2015 at 12:22:15 UTC, Dicebot wrote:
Unless LDC does some D specific WPO magic I am not aware of
this is not what your original statement was about.
llvm does normal WPO in a sense that compiled code is not opaque.
Erm. Either it is coding style issue or a language issue. Pi
On Sunday, 5 April 2015 at 12:17:09 UTC, Kagamin wrote:
On Saturday, 4 April 2015 at 19:59:46 UTC, Dicebot wrote:
We need solutions that can be reasonably implemented with
existing resources, not perfect solutions. Storing IR in
object files and using custom linker is "correct" approach for
WP
On Saturday, 4 April 2015 at 19:59:46 UTC, Dicebot wrote:
We need solutions that can be reasonably implemented with
existing resources, not perfect solutions. Storing IR in object
files and using custom linker is "correct" approach for WPO but
it is currently unaffordable.
Works for me with l
On Saturday, 4 April 2015 at 19:56:28 UTC, Dicebot wrote:
On Saturday, 4 April 2015 at 07:44:12 UTC, Atila Neves wrote:
On Friday, 3 April 2015 at 19:54:09 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 19:08:58 UTC, weaselcat wrote:
I just tried compiling one of my project. It has a makefile
On Saturday, 4 April 2015 at 16:58:23 UTC, Kagamin wrote:
On Friday, 3 April 2015 at 17:55:00 UTC, Dicebot wrote:
Complicates whole-program optimization possibilities. Old
school object files are simply not good enough to preserve
information necessary to produce optimized builds and we are
no
On Saturday, 4 April 2015 at 07:44:12 UTC, Atila Neves wrote:
On Friday, 3 April 2015 at 19:54:09 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 19:08:58 UTC, weaselcat wrote:
I just tried compiling one of my project. It has a makefile
that does separate compilation and a shell script I use for
On Saturday, 4 April 2015 at 07:44:12 UTC, Atila Neves wrote:
I'm of the opposite opinion. I don't care if full builds take
1h as long as incremental builds are as fast as possible. Why
would I keep doing full builds? That's like git cloning
multiple times. What for?
Full build is important w
On Friday, 3 April 2015 at 17:55:00 UTC, Dicebot wrote:
Complicates whole-program optimization possibilities. Old
school object files are simply not good enough to preserve
information necessary to produce optimized builds and we are
not in position to create own metadata + linker combo to
cir
On 4/4/15 1:30 AM, Atila Neves wrote:
On Friday, 3 April 2015 at 19:49:04 UTC, Andrei Alexandrescu wrote:
On 4/3/15 11:06 AM, Atila Neves wrote:
It's true that it's not always faster to compile each module separately,
I already knew that. It seems to me, however, that when that's actually
the
On Friday, 3 April 2015 at 19:49:04 UTC, Andrei Alexandrescu
wrote:
On 4/3/15 11:06 AM, Atila Neves wrote:
It's true that it's not always faster to compile each module
separately,
I already knew that. It seems to me, however, that when that's
actually
the case, the practical difference is neg
On Friday, 3 April 2015 at 19:45:38 UTC, Andrei Alexandrescu
wrote:
On 4/3/15 10:10 AM, Dicebot wrote:
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
. Separate compilation. One file changes, only one file gets
rebuilt
This immediately has caught my eye as huge "no" in the
descr
On 2015-04-03 19:54, Dicebot wrote:
2)
Ironically, it is just very slow. Those who come from C world got used
to using separate compilation to speed up rebuilds but it doesn't work
that way in D. It may look better if you change only 1 or 2 module but
as amount of modified modules grows, increm
On Friday, 3 April 2015 at 19:54:09 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 19:08:58 UTC, weaselcat wrote:
I just tried compiling one of my project. It has a makefile
that does separate compilation and a shell script I use for
unit testing which compiles everything in one go. The
makefi
On Friday, 3 April 2015 at 19:08:58 UTC, weaselcat wrote:
I just tried compiling one of my project. It has a makefile
that does separate compilation and a shell script I use for
unit testing which compiles everything in one go. The makefile
takes 5.3 seconds, does not including linking since it
On 4/3/15 12:07 PM, Jacob Carlborg wrote:
On 2015-04-03 20:06, Atila Neves wrote:
Interesting.
It's true that it's not always faster to compile each module separately,
I already knew that. It seems to me, however, that when that's actually
the case, the practical difference is negligible. Even
On Friday, 3 April 2015 at 18:06:42 UTC, Atila Neves wrote:
All I know is I've seen a definite improvement in my
edit-compile-unittest cycle by compiling modules separately.
How would the decoupling happen? Is the user supposed to
partition the binary into suitable static libraries? Or is the
On 4/3/15 11:06 AM, Atila Neves wrote:
It's true that it's not always faster to compile each module separately,
I already knew that. It seems to me, however, that when that's actually
the case, the practical difference is negligible. Even if 10x slower,
the linker will take longer anyway. Becaus
On 4/3/15 10:10 AM, Dicebot wrote:
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
. Separate compilation. One file changes, only one file gets rebuilt
This immediately has caught my eye as huge "no" in the description. We
must ban C style separate compilation, there is simply no w
On 2015-04-03 20:06, Atila Neves wrote:
Interesting.
It's true that it's not always faster to compile each module separately,
I already knew that. It seems to me, however, that when that's actually
the case, the practical difference is negligible. Even if 10x slower,
the linker will take longer
On Friday, 3 April 2015 at 19:07:09 UTC, Jacob Carlborg wrote:
On 2015-04-03 20:06, Atila Neves wrote:
Interesting.
It's true that it's not always faster to compile each module
separately,
I already knew that. It seems to me, however, that when that's
actually
the case, the practical differe
On 2015-04-03 19:03, Atila Neves wrote:
I wanted to work on this a little more before announcing it, but it
seems I'm going to be busy working on trying to get unit-threaded into
std.experimental so here it is:
http://code.dlang.org/packages/reggae
One thing I noticed immediately (unless I'm m
On Friday, 3 April 2015 at 17:55:00 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 17:25:51 UTC, Ben Boeckel wrote:
On Fri, Apr 03, 2015 at 17:10:31 +, Dicebot via
Digitalmars-d-announce wrote:
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
> . Separate compilation. One file ch
On Friday, 3 April 2015 at 17:55:00 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 17:25:51 UTC, Ben Boeckel wrote:
On Fri, Apr 03, 2015 at 17:10:31 +, Dicebot via
Digitalmars-d-announce wrote:
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
> . Separate compilation. One file ch
On Friday, 3 April 2015 at 17:59:22 UTC, Atila Neves wrote:
Well, I took your advice (and one of my acceptance tests is
based off of your simplified real-work example) and started
with the low-level any-command-will-do API first. I built the
high-level ones on top of that. It doesn't seem crazy
On Friday, 3 April 2015 at 17:40:42 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 17:17:50 UTC, Atila Neves wrote:
On Friday, 3 April 2015 at 17:13:41 UTC, Dicebot wrote:
Also I don't see any point in yet another meta build system.
The very point of initial discussion was about getting D only
On Friday, 3 April 2015 at 17:22:42 UTC, Atila Neves wrote:
On Friday, 3 April 2015 at 17:10:33 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
. Separate compilation. One file changes, only one file gets
rebuilt
This immediately has caught my eye as huge "no"
On Friday, 3 April 2015 at 17:25:51 UTC, Ben Boeckel wrote:
On Fri, Apr 03, 2015 at 17:10:31 +, Dicebot via
Digitalmars-d-announce wrote:
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
> . Separate compilation. One file changes, only one file gets
> rebuilt
This immediately h
On Friday, 3 April 2015 at 17:17:50 UTC, Atila Neves wrote:
On Friday, 3 April 2015 at 17:13:41 UTC, Dicebot wrote:
Also I don't see any point in yet another meta build system.
The very point of initial discussion was about getting D only
cross-platform solution that won't require installing an
On Fri, Apr 03, 2015 at 17:10:31 +, Dicebot via Digitalmars-d-announce
wrote:
> On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
> > . Separate compilation. One file changes, only one file gets
> > rebuilt
>
> This immediately has caught my eye as huge "no" in the
> description.
On Friday, 3 April 2015 at 17:10:33 UTC, Dicebot wrote:
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
. Separate compilation. One file changes, only one file gets
rebuilt
This immediately has caught my eye as huge "no" in the
description. We must ban C style separate compilation
On Friday, 3 April 2015 at 17:13:41 UTC, Dicebot wrote:
Also I don't see any point in yet another meta build system.
The very point of initial discussion was about getting D only
cross-platform solution that won't require installing any
additional software but working D compiler.
I was also t
Also I don't see any point in yet another meta build system. The
very point of initial discussion was about getting D only
cross-platform solution that won't require installing any
additional software but working D compiler.
On Friday, 3 April 2015 at 17:03:35 UTC, Atila Neves wrote:
. Separate compilation. One file changes, only one file gets
rebuilt
This immediately has caught my eye as huge "no" in the
description. We must ban C style separate compilation, there is
simply no way to move forward otherwise. At t
39 matches
Mail list logo
