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.
