On Friday, 15 January 2021 at 07:35:00 UTC, H. S. Teoh wrote:
On Thu, Jan 14, 2021 at 12:36:12PM +, claptrap via
Digitalmars-d-learn wrote: [...]
[...]
To be fair, the GC *has* improved over the years. Just not as
quickly as people would like, but it *has* improved.
[...]
Nice strate
On Friday, 15 January 2021 at 07:35:00 UTC, H. S. Teoh wrote:
To be fair, the GC *has* improved over the years. Just not as
quickly as people would like, but it *has* improved.
It cannot improve enough as a global collector without write
barriers. No language has been able to do this. Therefo
On Friday, 15 January 2021 at 06:15:06 UTC, dog2002 wrote:
On Thursday, 14 January 2021 at 22:28:19 UTC, Paul Backus wrote:
On Thursday, 14 January 2021 at 20:23:37 UTC, dog2002 wrote:
[...]
What code are you using to copy the bytes? If you're reading
the whole file into memory at once, that
On Fri, Jan 15, 2021 at 10:30 AM dog2002 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> ...
> Okay, the reason is incredibly stupid: using WinMain instead of
> main causes high memory usage. I don't know why, I use the same
> code. If I replace WinMain with main, the memory
On Friday, 15 January 2021 at 08:49:21 UTC, Imperatorn wrote:
Nice strategy, using GC and optimizing where you need it.
That's the whole point of being able to mix and match. Anyone
avoiding the GC completely is missing it (unless they really,
really, must be GC-less).
On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:
That's the whole point of being able to mix and match. Anyone
avoiding the GC completely is missing it (unless they really,
really, must be GC-less).
Has DMD switched to using the GC as the default?
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
I know there is other threads about null safety and the
"possible" ways to support this in D and so on.
This is only an open question to know what code patterns you
usually use to solve this situation in D
I'm writing a "persona
On Friday, 15 January 2021 at 11:05:56 UTC, Daniel Kozak wrote:
On Fri, Jan 15, 2021 at 10:30 AM dog2002 via
Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:
...
Okay, the reason is incredibly stupid: using WinMain instead of
main causes high memory usage. I don't know why, I us
GC cleans memory using the FIFO paradigm. Is it possible to
switch GC to work using the LIFO paradigm?
On 1/14/21 7:27 PM, ddcovery wrote:
On Thursday, 14 January 2021 at 20:23:08 UTC, Steven Schveighoffer wrote:
You could kinda automate it like:
struct NullCheck(T)
{
private T* _val;
auto opDispatch(string mem)() if (__traits(hasMember, T, mem)) {
alias Ret = typeof(() { return __
On 1/15/21 7:39 AM, MGW wrote:
GC cleans memory using the FIFO paradigm. Is it possible to switch GC to
work using the LIFO paradigm?
I'm not sure what you mean. I don't think there's any guaranteed order
for GC cleanup.
-Steve
On Friday, 15 January 2021 at 11:28:55 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:
That's the whole point of being able to mix and match. Anyone
avoiding the GC completely is missing it (unless they really,
really, must be GC-less).
Has DMD s
On 1/15/21 9:19 AM, Steven Schveighoffer wrote:
Something similar to BlackHole or WhiteHole. Essentially there's a
default action for null for all types/fields/methods, and everything
else is passed through.
And now reading the other thread about this above, it looks like this
type is alread
On Friday, 15 January 2021 at 14:25:09 UTC, Steven Schveighoffer
wrote:
On 1/15/21 9:19 AM, Steven Schveighoffer wrote:
Something similar to BlackHole or WhiteHole. Essentially
there's a default action for null for all
types/fields/methods, and everything else is passed through.
And now read
On Friday, 15 January 2021 at 14:24:40 UTC, welkam wrote:
You can use GC with D compiler by passing -lowmem flag. I didnt
measure but I heard it can increase compilation time by 3x.
Thanks for the info. 3x is a lot though, maybe it could be
improved with precise collection, but I assume that w
On Thursday, 14 January 2021 at 18:51:16 UTC, Ola Fosheim Grøstad
wrote:
One can follow the same kind of reasoning for D. It makes no
sense for people who want to stay high level and do batch
programming. Which is why this disconnect exists in the
community... I think.
The reasoning of why we
On 1/13/21 1:22 PM, apz28 wrote:
core.exception.InvalidMemoryOperationError@src\core\exception.d(647):
Invalid memory operation
I've struggled with this as well. It doesn't even tell you the original
usage point that causes the exception.
I believe stack traces are disabled from printing on
On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
The reasoning of why we do not implement write barriers is that
it will hurt low level programming. But I feel like if we drew
a ven diagram of people who rely on GC and those who do a lot
of writes trough a pointer we would get almost n
On Friday, 15 January 2021 at 14:59:18 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
avoid redundant pointers. For instance, a type for telling the
compiler that a pointer is non-owning.
I guess "non-owning" is the wrong term. I mean pointers that ar
On Friday, 15 January 2021 at 14:24:40 UTC, welkam wrote:
No. And it will never will. Currently DMD uses custom allocator
for almost everything. It works as follows. Allocate a big
chunk(1MB) of memory using malloc. Have a internal pointer that
points to the beginning of unallocated memory. W
On Friday, 15 January 2021 at 14:50:00 UTC, welkam wrote:
On Thursday, 14 January 2021 at 18:51:16 UTC, Ola Fosheim
Grøstad wrote:
One can follow the same kind of reasoning for D. It makes no
sense for people who want to stay high level and do batch
programming. Which is why this disconnect exi
On Friday, 15 January 2021 at 15:18:31 UTC, IGotD- wrote:
Bump the pointer is a very fast way to allocate memory but what
is more interesting is what happens when you return the memory.
What does the allocator do with chunks of free memory? Does it
put it in a free list, does it merge chunks? I
On Friday, 15 January 2021 at 15:20:05 UTC, jmh530 wrote:
Hypothetically, would it be possible for users to supply their
own garbage collector that uses write barriers?
Yes. You could translate Google Chrome's Oilpan to D. It uses
library smart pointers for dirty-marking. But it requires you t
On Friday, 15 January 2021 at 14:35:55 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 15 January 2021 at 14:24:40 UTC, welkam wrote:
You can use GC with D compiler by passing -lowmem flag. I
didnt measure but I heard it can increase compilation time by
3x.
Thanks for the info. 3x is a lot
Take it
On Fri, Jan 15, 2021 at 03:18:31PM +, IGotD- via Digitalmars-d-learn wrote:
[...]
> Bump the pointer is a very fast way to allocate memory but what is
> more interesting is what happens when you return the memory. What does
> the allocator do with chunks of free memory? Does it put it in a free
On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:
That's the whole point of being able to mix and match. Anyone
avoiding the GC completely is missing it (unless they really,
really, must be GC-less).
+1
mix and match is a different style versus only having a GC, or
only having
On Friday, 15 January 2021 at 15:18:31 UTC, IGotD- wrote:
I have a feeling that bump the pointer is not the complete
algorithm that D uses because of that was the only one, D would
waste a lot of memory.
Freeing memory is for loosers :D
https://issues.dlang.org/show_bug.cgi?id=21248
DMD alloc
I believe so. I've never used OpenAL so it may have additional
restrictions with multithreading, but from a simple "This
function is only ever executed on one thread at a time", your
above suggestions should work.
Apologies for the late reply.
No worry and thank you. I found the low-lock pat
On Friday, 15 January 2021 at 16:04:02 UTC, ludo wrote:
I believe so. I've never used OpenAL so it may have additional
restrictions with multithreading, but from a simple "This
function is only ever executed on one thread at a time", your
above suggestions should work.
Apologies for the late
On Friday, 15 January 2021 at 15:48:07 UTC, welkam wrote:
On Friday, 15 January 2021 at 14:35:55 UTC, Ola Fosheim Grøstad
wrote:
improved with precise collection
Precise GC is slower than default GC.
D does not have a fully precise GC. The "precise" collector still
scans things conservativel
On Friday, 15 January 2021 at 12:39:30 UTC, MGW wrote:
GC cleans memory using the FIFO paradigm. Is it possible to
switch GC to work using the LIFO paradigm?
AFAIK the GC just sweeps, and the only queue is for destructors
(unreachable memory) iirc
On Friday, 15 January 2021 at 15:50:59 UTC, Guillaume Piolat
wrote:
On Friday, 15 January 2021 at 11:11:14 UTC, Mike Parker wrote:
That's the whole point of being able to mix and match. Anyone
avoiding the GC completely is missing it (unless they really,
really, must be GC-less).
+1
mix and
On Friday, 15 January 2021 at 15:36:37 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 15 January 2021 at 15:20:05 UTC, jmh530 wrote:
Hypothetically, would it be possible for users to supply their
own garbage collector that uses write barriers?
Yes. You could translate Google Chrome's Oilpan to D.
On Friday, 15 January 2021 at 15:50:50 UTC, H. S. Teoh wrote:
DMD *never* frees anything. *That's* part of why it's so fast;
it completely drops the complexity of tracking free lists and
all of that jazz.
That's also why it's a gigantic memory hog that can be a big
embarrassment when run o
On 1/6/21 12:05 PM, ludo wrote:
I read in the documentation
"Static constructors are used to initialize static class members with
values that cannot be computed at compile time"
I try to understand the design of the following code:
---
class OpenAL
{
static string[int] ALErrorLookup;
On Friday, 15 January 2021 at 16:21:43 UTC, jmh530 wrote:
On Friday, 15 January 2021 at 15:36:37 UTC, Ola Fosheim Grøstad
wrote:
The library smart pointers would make it difficult to interact
with existing D GC code though.
Yes. So it would be better to do it automatically in the compiler
for
On Friday, 15 January 2021 at 16:21:18 UTC, Ola Fosheim Grøstad
wrote:
What do you mean by "mix and match"? If it means shutting down
the GC after initialization then it can easily backfire for
more complicated software that accidentally calls code that
relies on the GC.
I mean: "using GC,
On Friday, 15 January 2021 at 16:26:59 UTC, Guillaume Piolat
wrote:
Until someone can describe a strategy that works for a full
application, e.g. an animation-editor or something like that,
it is really difficult to understand what is meant by it.
Personal examples:
- The game Vibrant uses GC
On Friday, 15 January 2021 at 14:19:35 UTC, Steven Schveighoffer
wrote:
On 1/14/21 7:27 PM, ddcovery wrote:
On Thursday, 14 January 2021 at 20:23:08 UTC, Steven
Schveighoffer wrote:
You could kinda automate it like:
struct NullCheck(T)
{
private T* _val;
auto opDispatch(string mem)() if
On Fri, Jan 15, 2021 at 04:22:59PM +, IGotD- via Digitalmars-d-learn wrote:
[...]
> Are we talking about the same things here? You mentioned DMD but I was
> talking about programs compiled with DMD (or GDC, LDC), not the nature
> of the DMD compiler in particular.
>
> Bump the pointer and neve
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
Most people get to know GC trough Java or C#. Those languages
promote the use of OOP and they say tha
On Friday, 15 January 2021 at 16:22:59 UTC, IGotD- wrote:
[snip]
Are we talking about the same things here? You mentioned DMD
but I was talking about programs compiled with DMD (or GDC,
LDC), not the nature of the DMD compiler in particular.
Bump the pointer and never return any memory might
is this possible? if so, how?
On Friday, 15 January 2021 at 17:02:32 UTC, Jack wrote:
is this possible? if so, how?
You can add extra options for for platform and compiler, and IIRC
for build type too.
For example like this for lflags, it might complain about the
order so just follow the instructions.
"lflags-debug"
"
On Friday, 15 January 2021 at 14:25:09 UTC, Steven Schveighoffer
wrote:
On 1/15/21 9:19 AM, Steven Schveighoffer wrote:
Something similar to BlackHole or WhiteHole. Essentially
there's a default action for null for all
types/fields/methods, and everything else is passed through.
And now read
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
This is only an open question to know what code patterns you
usually use to solve this situation in D:
if(person.father.father.name == "Peter") doSomething();
if(person.father.age > 80 ) doSomething();
knowing that *person*, or
On Friday, 15 January 2021 at 16:37:46 UTC, Ola Fosheim Grøstad
wrote:
But when do you call collect? Do you not create more and more
long-lived objects?
Calling collect() isn't very good, it's way better to ensure the
GC heap is relatively small, hence easy to traverse.
You can use -gc=profi
On Friday, 15 January 2021 at 18:43:44 UTC, Guillaume Piolat
wrote:
Calling collect() isn't very good, it's way better to ensure
the GC heap is relatively small, hence easy to traverse.
You can use -gc=profile for this (noting that things that can't
contain pointer, such as ubyte[], scan way fas
On Friday, 15 January 2021 at 18:55:27 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 15 January 2021 at 18:43:44 UTC, Guillaume Piolat
wrote:
Calling collect() isn't very good, it's way better to ensure
the GC heap is relatively small, hence easy to traverse.
You can use -gc=profile for this (notin
On Friday, 15 January 2021 at 19:37:12 UTC, Guillaume Piolat
wrote:
A small GC heap is sufficient.
There is this blog post where there was a quantitative measure
of the sub-1ms D GC heap size.
That's ok for a small game, but not for applications that grow
over time or projects where the requi
On Friday, 15 January 2021 at 12:39:30 UTC, MGW wrote:
GC cleans memory using the FIFO paradigm. Is it possible to
switch GC to work using the LIFO paradigm?
As others already said, the current GC isn't FIFO; it just scans
everything once in a while a frees whatever it can, new or old.
Howev
On Fri, Jan 15, 2021 at 08:19:18PM +, tsbockman via Digitalmars-d-learn
wrote:
[...]
> However, generational GCs are somewhat closer to LIFO than what we
> have now, which does provide some performance gains under common usage
> patterns. People have discussed adding a generational GC to D in
On Friday, 15 January 2021 at 07:35:00 UTC, H. S. Teoh wrote:
(1) Refactored one function called from an inner loop to reuse
a buffer instead of allocating a new one each time, thus
eliminating a large amount of garbage from small allocations;
<...>
The result was about 40-50% reduction in runt
On Friday, 15 January 2021 at 19:49:34 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 15 January 2021 at 19:37:12 UTC, Guillaume Piolat
wrote:
A small GC heap is sufficient.
There is this blog post where there was a quantitative measure
of the sub-1ms D GC heap size.
That's ok for a small game, b
On Friday, 15 January 2021 at 21:15:29 UTC, aberba wrote:
On Friday, 15 January 2021 at 19:49:34 UTC, Ola Fosheim Grøstad
wrote:
[...]
Isn't it more theoretical/imaginary/hypothetical than something
really measured from a real-world use case? Almost all large
software use cases I've seen use
On Friday, 15 January 2021 at 21:15:29 UTC, aberba wrote:
Isn't it more theoretical/imaginary/hypothetical than something
really measured from a real-world use case? Almost all large
software use cases I've seen used mix and match.
No?! Chrome has a garbage collector because JavaScript acquire
On Fri, Jan 15, 2021 at 09:04:13PM +, welkam via Digitalmars-d-learn wrote:
> On Friday, 15 January 2021 at 07:35:00 UTC, H. S. Teoh wrote:
> > (1) Refactored one function called from an inner loop to reuse a
> > buffer instead of allocating a new one each time, thus eliminating a
> > large amo
On Friday, 15 January 2021 at 21:18:55 UTC, aberba wrote:
TL;DR:
In summation, the garbage collection system is a robust part
of Unreal Engine that affords C++ programmers a lot of safety
from memory leaks, as well as convenience. With this
high-level discussion, I was aiming to introduce the
On Friday, 15 January 2021 at 21:49:07 UTC, H. S. Teoh wrote:
On Fri, Jan 15, 2021 at 09:04:13PM +, welkam via
Digitalmars-d-learn wrote:
[...]
As the joke goes, "you can write assembly code in any
language". :-D If you code in a sloppy way, it doesn't matter
what language you write in,
On Friday, 15 January 2021 at 22:13:01 UTC, Max Haughton wrote:
I think the way forward is some robust move semantics and
analysis like Rust. I suppose ideally we would have some kind
of hidden ARC behind the scenes but I don't know how that would
play with structs.
If they are heap allocated
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
I know there is other threads about null safety and the
"possible" ways to support this in D and so on.
[...]
If it's not a bother, I'd like to know how you usually approach
it
[...]
Thanks!!!
I have a opDispatch solution here [
On Friday, 15 January 2021 at 19:49:34 UTC, Ola Fosheim Grøstad
wrote:
Many open source projects (and also some commercial ones) work
ok for small datasets, but tank when you increase the dataset.
So "match and mix" basically means use it for prototyping, but
do-not-rely-on-it-if-you-can-avoi
I'm having issues when trying to use a template alias as a
template specialisation.
When using the following:
alias Vec(uint size, Type) = Mat!(size, 1, Type);
void setUniform(V : Vec!(L, bool), int L)(string name, V value)
{...}
Vec!(4, bool) a;
setUniform("test", a);
I get the followin
On Saturday, 16 January 2021 at 01:21:24 UTC, Paul wrote:
I'm having issues when trying to use a template alias as a
template specialisation.
When using the following:
alias Vec(uint size, Type) = Mat!(size, 1, Type);
void setUniform(V : Vec!(L, bool), int L)(string name, V
value) {...}
V
On Saturday, 16 January 2021 at 01:38:38 UTC, Paul Backus wrote:
You have encountered issue 1807:
https://issues.dlang.org/show_bug.cgi?id=1807
Ah I see, thank you, sad to see several DIP's I'd be interested
in are postponed :(
Thanks for the workaround hint, I'll probably be using that.
On Saturday, 16 January 2021 at 01:21:24 UTC, Paul wrote:
I'm having issues when trying to use a template alias as a
template specialisation.
When using the following:
alias Vec(uint size, Type) = Mat!(size, 1, Type);
void setUniform(V : Vec!(L, bool), int L)(string name, V
value) {...}
V
66 matches
Mail list logo
