On 06.12.20 06:16, Bruce Carneal via Digitalmars-d-learn wrote:
How difficult would it be to add a, selectable, low-latency GC to dlang?
Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC
in hand"?
I've heard Walter m
On 06.12.20 06:16, Bruce Carneal via Digitalmars-d-learn wrote:
How difficult would it be to add a, selectable, low-latency GC to dlang?
Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC
in hand"?
I've heard Walter m
On Sunday, 6 December 2020 at 17:28:52 UTC, Bruce Carneal wrote:
D is good for systems level work but that's not all. I use it
for projects where, in the past, I'd have split the work
between two languages (Python and C/C++). I much prefer
working with a single language that spans the problem
On Sunday, 6 December 2020 at 17:35:19 UTC, IGotD- wrote:
Is automatic atomic reference counting a contender for kernels?
In kernels you want to reduce the increase/decrease of the
counts. Therefore the Rust approach using 'clone' is better
unless there is some optimizer that can figure it out.
On Sunday, 6 December 2020 at 15:44:32 UTC, Ola Fosheim Grøstad
wrote:
It was more a hypothetical, as read barriers are too expensive.
But write barriers should be ok, so a single-threaded
incremental collector could work well if D takes a principled
stance on objects not being 'shared' not b
On Sunday, 6 December 2020 at 16:42:00 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 14:44:25 UTC, Paulo Pinto wrote:
And while on the subject of low level programming in JVM or
.NET.
https://www.infoq.com/news/2020/12/net-5-runtime-improvements/
Didnt say anything about low
On Sunday, 6 December 2020 at 14:44:25 UTC, Paulo Pinto wrote:
And while on the subject of low level programming in JVM or
.NET.
https://www.infoq.com/news/2020/12/net-5-runtime-improvements/
Didnt say anything about low level, only simd intrinsics, which
isnt really low level?
It also sta
On Sunday, 6 December 2020 at 14:11:41 UTC, Max Haughton wrote:
On Sunday, 6 December 2020 at 11:35:17 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 11:27:39 UTC, Max Haughton wrote:
[...]
No, unique doesnt need indirection, neither does ARC, we put
the ref count at a negativ
On Sunday, 6 December 2020 at 14:45:21 UTC, Bruce Carneal wrote:
Well, you could in theory avoid putting owning pointers on the
stack/globals or require that they are registered as gc roots.
Then you don't have to scan the stack. All you need then is
write barriers. IIRC
'shared' with teeth?
ot of effort on sync
instructions in code gen to lower the latency AFAIK.
So, much of the difficulty in bringing low-latency GC to dlang
would be the large code gen changes required. If it is a
really big effort then that is all we need to know. Not worth
it until we can see a big payof
On Sunday, 6 December 2020 at 08:12:58 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 07:45:17 UTC, Bruce Carneal wrote:
GCs scan memory, sure. Lots of variations. Not germane. Not
a rationale.
We need to freeze the threads when collecting stacks/globals.
D is employed at mu
On Sunday, 6 December 2020 at 11:35:17 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 11:27:39 UTC, Max Haughton wrote:
[...]
No, unique doesnt need indirection, neither does ARC, we put
the ref count at a negative offset.
shared_ptr is a fat pointer with the ref count as a s
On Sunday, 6 December 2020 at 12:58:44 UTC, IGotD- wrote:
I was thinking about how to deal with this in D and the
question is if it would be better to be able to control move as
default per type basis. This way we can implement Rust style
reference counting without intruding too much on the res
On Sunday, 6 December 2020 at 11:07:50 UTC, Ola Fosheim Grostad
wrote:
ARC can be done incrementally, we can do it as a library first
and use a modified version existing GC for detecting failed
borrows at runtime during testing.
But all libraries that use owning pointers need ownership to be
On Sunday, 6 December 2020 at 11:27:39 UTC, Max Haughton wrote:
ARC with a library will have overhead unless the compiler/ABI
is changed e.g. unique_ptr in C++ has an indirection.
No, unique doesnt need indirection, neither does ARC, we put the
ref count at a negative offset.
shared_ptr is a
On Sunday, 6 December 2020 at 11:07:50 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 10:44:39 UTC, Max Haughton wrote:
On Sunday, 6 December 2020 at 05:29:37 UTC, Ola Fosheim
Grostad wrote:
It has to be either some kind of heavily customisable small GC
(i.e. with our resources t
On Sunday, 6 December 2020 at 10:44:39 UTC, Max Haughton wrote:
On Sunday, 6 December 2020 at 05:29:37 UTC, Ola Fosheim Grostad
wrote:
It has to be either some kind of heavily customisable small GC
(i.e. with our resources the GC cannot please everyone), or
arc. The GC as it is just hurts the l
On Sunday, 6 December 2020 at 05:29:37 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 05:16:26 UTC, Bruce Carneal wrote:
How difficult would it be to add a, selectable, low-latency GC
to dlang?
Is it closer to "we cant get there from here" or "no big deal
if y
On Sunday, 6 December 2020 at 08:59:49 UTC, Ola Fosheim Grostad
wrote:
Well, you could in theory avoid putting owning pointers on the
stack/globals or require that they are registered as gc roots.
Then you don't have to scan the stack. All you need then is
write barriers. IIRC
Abd read barrie
AFAIK.
So, much of the difficulty in bringing low-latency GC to dlang
would be the large code gen changes required. If it is a
really big effort then that is all we need to know. Not worth
it until we can see a big payoff and have more resources.
Well, you could in theory avoid putting o
o sync threads this has a rather profound impact on code
generation. They have spent a lot of effort on sync
instructions in code gen to lower the latency AFAIK.
So, much of the difficulty in bringing low-latency GC to dlang
would be the large code gen changes required. If it is a really
big e
On Sunday, 6 December 2020 at 07:45:17 UTC, Bruce Carneal wrote:
GCs scan memory, sure. Lots of variations. Not germane. Not
a rationale.
We need to freeze the threads when collecting stacks/globals.
D is employed at multiple "levels". Whatever level you call
it, Go and modern JVMs employ
On Sunday, 6 December 2020 at 06:52:41 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 05:41:05 UTC, Bruce Carneal wrote:
OK. Some rationale? Do you, for example, believe that
no-probable-dlanger could benefit from a low-latency GC? That
it is too hard to implement? That the
On Sunday, 6 December 2020 at 05:41:05 UTC, Bruce Carneal wrote:
OK. Some rationale? Do you, for example, believe that
no-probable-dlanger could benefit from a low-latency GC? That
it is too hard to implement? That the language is somehow
incompatible? That ...
The GC needs to scan all
On Sunday, 6 December 2020 at 05:29:37 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 05:16:26 UTC, Bruce Carneal wrote:
How difficult would it be to add a, selectable, low-latency GC
to dlang?
Is it closer to "we cant get there from here" or "no big deal
if y
On Sunday, 6 December 2020 at 05:16:26 UTC, Bruce Carneal wrote:
How difficult would it be to add a, selectable, low-latency GC
to dlang?
Is it closer to "we cant get there from here" or "no big deal
if you already have the low-latency GC in hand"?
I've heard W
How difficult would it be to add a, selectable, low-latency GC to
dlang?
Is it closer to "we cant get there from here" or "no big deal if
you already have the low-latency GC in hand"?
I've heard Walter mention performance issues (write barriers
IIRC). I'm al
On Wednesday, 6 July 2016 at 16:58:45 UTC, chmike wrote:
In case you missed it
https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.emwja62y1
This should have been posted in General.
In case you missed it
https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.emwja62y1
29 matches
Mail list logo
