On Thursday, 10 March 2016 at 18:49:28 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan
wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei
Alexandrescu wrote:
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it
lock-free.
Currently, GC lock cause some serious performance
penalties for
multithreaded code when frequent allocations take place.
I agree. A first step would be easy to do with
std.allocator's thread-local freelists. -- Andrei
I was looking into this, but I am slightly hesitant. Should
the gc use something in std.experimental? Or should we
think that's ok?
I also know that there are some people that think we should
avoid using Phobos in druntime.
There's no problem in using std.experimental.* internally,
because if the API changes, the one who changes the API will
also need to change all internal usages, otherwise his pull
request won't compile.
About using Phobos in Druntime - you can't directly import
Phobos, since it's files are not present when Druntime is
built.
But we allready need existing D compiler to build D frontend,
so maybe we can use this full D compiler for building
druntime in the future?
The build process looks something like this currently:
(a bit simplified)
1. Download old dmd.
2. Build new dmd with 1.
3. Build druntime with 2.
4. Build phobos with 2 and link it with 3.
5. Package 2, 3 and 4 into a release zip
You can't use 1 for building 3 (or 4), because 3 (or 4) may
depend on a new feature only present in 2. Also you can't rely
on 5 for building 3 (or 4) because you'll get a cyclic
dependency.
I know how it works now :). But if D is stable enought 1
should be good enought to do 3 and 4 (yes you can't rely on
features and fixes from 2). I think we should avoid to use
latest features when developing dmd, druntime and phobos (maybe
we should use only some subset or make some rules like new
version must be compilable by 3 previous version of dmd)
Well for 4. maybe, but after a couple of years... Most of the
time Phobos can't be compiled with an older version of DMD not
because it relies on new features, but because there are bugs in
the older version of DMD.
As for 3. - druntime is very tightly coupled with the compiler.
Quite often changes in the compiler rely on changes in druntime -
e.g. the new DWARF exceptions, C++ and Objective-C support,
better code coverage and GC profiling, things in object.d,
built-in AAs and arrays, linking with MSVC 2015 libc, shared
libraries, TLS, etc.
On the other hand, I think that using Phobos in DMDFE is a good
idea and is far more likely to happen.