On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote:
Personally, when I make a strong claim about something and find
that I am wrong (the claim that D needs to scan every pointer),
I take a step back and consider my view rather than pressing
harder. It's beautiful to be wrong
On Monday, 14 September 2015 at 00:53:58 UTC, Jonathan M Davis
wrote:
Only the stack and the GC heap get scanned unless you tell the
GC about memory that was allocated by malloc or some other
mechanism. malloced memory won't be scanned by default. So, if
you're using the GC minimally and
On Monday, 14 September 2015 at 08:57:07 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 14 September 2015 at 00:53:58 UTC, Jonathan M Davis
wrote:
So, while the fact that D's GC is less than stellar is
certainly a problem, and we would definitely like to improve
that, the idioms that D code
On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote:
An associate who sold a decent sized marketing group
Should read marketmaking. Making prices in listed equity options.
On Monday, September 14, 2015 01:12:02 Ola Fosheim Grostad via
Digitalmars-d-learn wrote:
> On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis
> wrote:
> > Regardless, idiomatic D involves a lot more stack allocations
> > than you often get even in C++, so GC usage tends to be low in
On Monday, 14 September 2015 at 20:54:55 UTC, Jonathan M Davis
wrote:
On Monday, September 14, 2015 01:12:02 Ola Fosheim Grostad via
Digitalmars-d-learn wrote:
On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis
wrote:
> Regardless, idiomatic D involves a lot more stack
>
On Monday, September 14, 2015 14:19:30 Ola Fosheim Grøstad via
Digitalmars-d-learn wrote:
> On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote:
> The claim is correct: you need to follow every pointer that
> through some indirection may lead to a pointer that may point
> into the
On Monday, 14 September 2015 at 20:34:03 UTC, Jonathan M Davis
wrote:
I'm not sure why it wouldn't be suitable for the typical use
case. It's quite performant. It would still not be suitable for
many games and environments that can't afford to stop the world
for more than a few milliseconds,
On Monday, 14 September 2015 at 20:54:55 UTC, Jonathan M Davis
wrote:
So, you _can_ have low heap allocation in a C++ program, and
many people do, but from what I've seen, that really isn't the
norm across the C++ community in general.
- Jonathan M Davis
Fully agreed, C++ in the wild
On Monday, 14 September 2015 at 00:53:58 UTC, Jonathan M Davis
wrote:
So, while the fact that D's GC is less than stellar is
certainly a problem, and we would definitely like to improve
that, the idioms that D code typically uses seriously reduce
the number of performance problems that we get.
On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
wrote:
But the idea that your average D program is going to run into
problems with the GC while using Phobos is just plain wrong.
The folks who need to care are the rare folks who need extreme
enough performance that they can't
On Saturday, September 12, 2015 13:42:42 Prudence via Digitalmars-d-learn wrote:
> On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M Davis
> wrote:
> > On Friday, September 11, 2015 23:29:05 Laeeth Isharc via
> > Digitalmars-d-learn wrote:
> >> On Friday, 11 September 2015 at 21:58:28
On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
I don't care about "maybe" working. Since the array is hidden
inside a class I can control who and how it is used and deal
with the race conditions.
Looks like destruction slipped out of your control. That is
solved by making
On Sunday, 13 September 2015 at 16:53:20 UTC, ponce wrote:
GC is basically ok for anything soft-realtime, where you
already spend a lot of time to go fast enough. And if you want
hard-realtime, well you wouldn't want malloc either.
It's a non-problem.
If this was true then Go would not have
On Sunday, 13 September 2015 at 16:58:22 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
wrote:
the GC heavily. And the reality of the matter is that the vast
majority of programs will have _no_ problems with using the GC
so long as they don't use
On Sunday, 13 September 2015 at 17:16:02 UTC, ponce wrote:
On Sunday, 13 September 2015 at 17:00:30 UTC, Ola Fosheim
If this was true then Go would not have a concurrent collector.
I was speaking of the D language.
Go only added concurrent GC now at version 1.5 and keep improving
it to
On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
wrote:
the GC heavily. And the reality of the matter is that the vast
majority of programs will have _no_ problems with using the GC
so long as they don't use it heavily. Programming like you're
in Java and allocating everything on
On Sunday, 13 September 2015 at 17:00:30 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 13 September 2015 at 16:53:20 UTC, ponce wrote:
GC is basically ok for anything soft-realtime, where you
already spend a lot of time to go fast enough. And if you want
hard-realtime, well you wouldn't want
On Sunday, 13 September 2015 at 17:16:02 UTC, ponce wrote:
On Sunday, 13 September 2015 at 17:00:30 UTC, Ola Fosheim
Grøstad wrote:
On Sunday, 13 September 2015 at 16:53:20 UTC, ponce wrote:
GC is basically ok for anything soft-realtime, where you
already spend a lot of time to go fast enough.
On Sunday, 13 September 2015 at 19:39:20 UTC, Ola Fosheim Grostad
wrote:
The theoretical limit for 10ms mark sweep collection on current
desktop cpus is 60 megabytes at peak performance. That means
you'll have to stay below 30 MiB in total memory use with
pointers.
30 MiB of scannable
On Sunday, September 13, 2015 16:53:18 ponce via Digitalmars-d-learn wrote:
> On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
> wrote:
> > But the idea that your average D program is going to run into
> > problems with the GC while using Phobos is just plain wrong.
> > The folks who
On Sunday, September 13, 2015 16:58:21 Ola Fosheim Grøstad via
Digitalmars-d-learn wrote:
> On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
> wrote:
> > the GC heavily. And the reality of the matter is that the vast
> > majority of programs will have _no_ problems with using the GC
On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis
wrote:
stop-the-world GC. For instance, this has come up in
discussions on games where a certain framerate needs to be
maintained. Even a 100 ms stop would be way too much for them.
In fact, it came up with the concurrent GC that
On Sunday, September 13, 2015 17:14:05 Prudence via Digitalmars-d-learn wrote:
> On Sunday, 13 September 2015 at 16:58:22 UTC, Ola Fosheim Grøstad
> wrote:
> > On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
> > wrote:
> >> the GC heavily. And the reality of the matter is that the
On Saturday, 12 September 2015 at 22:36:00 UTC, Laeeth Isharc
wrote:
Thank you for this. How large is the allocation for closure
for a delegate? Just a pair of pointers?
It depends on what the delegate needs to capture. It makes a copy
of the local variables the function is referencing.
On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:
Using it at all is a problem because one doesn't know when and
where.
It is called when the collect function is called and where it was
called from.
D's garbage collector isn't magic, it is just a function that
frees memory
On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M
Davis wrote:
Aside from the few classes in Phobos, its GC usage is almost
entirely restricted to when it allocates arrays or when it has
to allocate a closure for a delegate, which can happen in some
cases when passing predicates to
On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:
Saying that it doesn't use it most of the time is not an
answer/solution. Using it at all is a problem because one
doesn't know when and where. I realize there is a switch
now(-vgc), and maybe that is the solution, but you say
On Friday, September 11, 2015 23:29:05 Laeeth Isharc via Digitalmars-d-learn
wrote:
> On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
> > On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
> >> Oh really?!?! I thought slicing used the GC? Is this a recent
> >>
On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M Davis
wrote:
On Friday, September 11, 2015 23:29:05 Laeeth Isharc via
Digitalmars-d-learn wrote:
On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe
wrote:
> [...]
Seems to be quite a lot of FUD wrt use of standard library and
On Friday, 11 September 2015 at 14:54:00 UTC, Prudence wrote:
But in this case it is static, so why does it matter? Do you
have any ideas how to wrap it or fix this?
It matters exactly because it is static. A code written for
single-threaded environment may not work correctly in shared
On Friday, 11 September 2015 at 16:04:22 UTC, Kagamin wrote:
On Friday, 11 September 2015 at 14:54:00 UTC, Prudence wrote:
But in this case it is static, so why does it matter? Do you
have any ideas how to wrap it or fix this?
It matters exactly because it is static. A code written for
I get only one error:
Error: non-shared method std.container.array.Array!(void
delegate()).Array.~this is not callable using a shared object.
It will try to destruct the array on program termination, but it
requires the destructor to be aware of the shared context.
You can try to write a wrapper for the array that it aware of
concurrency.
On Friday, September 11, 2015 00:50:13 Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Friday, 11 September 2015 at 00:48:28 UTC, Prudence wrote:
> > static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;
>
> Try just using a regular array instead of the library Array.
>
>
> static bool
On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
I don't care about "maybe" working. Since the array is hidden
inside a class I can control who and how it is used and deal
with the race conditions.
You could use __gshared instead of shared. It means put it in
non-tls storage,
On Friday, 11 September 2015 at 20:06:53 UTC, Prudence wrote:
Can you back up this claim? Not saying your lying, I'd just
like to know it's true for a fact?
The list of things that trigger the GC is pretty short. See the
bottom of this page:
http://dlang.org/garbage.html
Basically, the
On Friday, 11 September 2015 at 19:27:49 UTC, Adam D. Ruppe wrote:
On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
I don't care about "maybe" working. Since the array is hidden
inside a class I can control who and how it is used and deal
with the race conditions.
You could use
On Friday, 11 September 2015 at 20:30:37 UTC, Adam D. Ruppe wrote:
On Friday, 11 September 2015 at 20:06:53 UTC, Prudence wrote:
Can you back up this claim? Not saying your lying, I'd just
like to know it's true for a fact?
The list of things that trigger the GC is pretty short. See the
On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
Oh really?!?! I thought slicing used the GC? Is this a recent
development or always been that way?
Always been that way. A D slice is just a C pointer + length
On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
Oh really?!?! I thought slicing used the GC? Is this a recent
development or always been that way?
Always been that way. A D slice is just a C pointer + length
packed together. A slice simply increments the pointer and/or
On Friday, 11 September 2015 at 04:28:52 UTC, Prudence wrote:
I thought about that but then I have to rely on the GC for some
simple things. Doesn't seem like the right way to go.
Since it is static, it will never be collected anyway, so you
could just use it and it'll work for convenience
On Friday, 11 September 2015 at 13:12:14 UTC, Adam D. Ruppe wrote:
On Friday, 11 September 2015 at 04:28:52 UTC, Prudence wrote:
I thought about that but then I have to rely on the GC for
some simple things. Doesn't seem like the right way to go.
Since it is static, it will never be collected
On Friday, 11 September 2015 at 07:41:10 UTC, Kagamin wrote:
I get only one error:
Error: non-shared method std.container.array.Array!(void
delegate()).Array.~this is not callable using a shared object.
It will try to destruct the array on program termination, but
it requires the destructor
On Friday, 11 September 2015 at 14:47:15 UTC, Prudence wrote:
If it's never collected and the GC scans it every time, it
means it adds a constant overhead to the GC for absolutely no
reason, right?
GC overhead isn't quite constant, it happens only when you call
for a collection cycle.
But
On Friday, 11 September 2015 at 00:48:28 UTC, Prudence wrote:
static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;
Try just using a regular array instead of the library Array.
static bool delegate(int, WPARAM, LPARAM)[] callbacks;
my guess is the Array library thing isn't marked as
On Friday, 11 September 2015 at 00:50:15 UTC, Adam D. Ruppe wrote:
On Friday, 11 September 2015 at 00:48:28 UTC, Prudence wrote:
static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;
Try just using a regular array instead of the library Array.
static bool delegate(int, WPARAM,
47 matches
Mail list logo
