Re: Avoiding GC in D and code consistancy
On 12/31/17 7:50 AM, Steven Schveighoffer wrote:
Note, you can use a "sink" version of toString as well, and avoid the gc:
void toString(void delegate(const(char)[]) sink) @nogc
{
// use formatValue to push into the sink
}
I guess I'm missing some parameters here, go with what Seb linked to :)
-Steve
Re: Avoiding GC in D and code consistancy
On 12/31/17 6:16 AM, Tim Hsu wrote:
On Sunday, 31 December 2017 at 07:32:50 UTC, Ali Çehreli wrote:
On 12/30/2017 11:16 PM, Tim Hsu wrote:
> Struct version of Vector3f can't derive toString
> method. writeln() prints unformated struct members. I know I
can use
> helper function here. But is there any other way?
The normal way that I know is to insert a function like the following
into Vector3f:
string toString() {
import std.string : format;
return format("%s,%s,%s", x, y, z);
}
> class version of Vector3f. Require new operator in
opBinary(). scoped!
> won't work here.
>
> Is there a better to write vector3f class while avoiding GC?
Yeah, it doesn't make sense that a type of x, y, z should be a class.
I would stay with a struct here.
Sorry I am a bit disappointed. It seems writeln itself will check if the
struct to be printed has toString. If not, it use default struct printer.
Note, you can use a "sink" version of toString as well, and avoid the gc:
void toString(void delegate(const(char)[]) sink) @nogc
{
// use formatValue to push into the sink
}
-Steve
Re: Avoiding GC in D and code consistancy
On Sunday, 31 December 2017 at 07:16:46 UTC, Tim Hsu wrote: I came from C++ looking forward to D. Some languages require programmers to use GC all the time. However, A lot of time we don't really need GC especially when the time of destruction is deterministic in compile time. [...] You can use a custom toString method which doesn't do any allocations: https://wiki.dlang.org/Defining_custom_print_format_specifiers However, the building blocks (formattedWrite and writeln) aren't "@nogc" at the moment.
Re: Avoiding GC in D and code consistancy
On Sunday, 31 December 2017 at 07:32:50 UTC, Ali Çehreli wrote:
On 12/30/2017 11:16 PM, Tim Hsu wrote:
> Struct version of Vector3f can't derive toString
> method. writeln() prints unformated struct members. I know I
can use
> helper function here. But is there any other way?
The normal way that I know is to insert a function like the
following into Vector3f:
string toString() {
import std.string : format;
return format("%s,%s,%s", x, y, z);
}
> class version of Vector3f. Require new operator in
opBinary(). scoped!
> won't work here.
>
> Is there a better to write vector3f class while avoiding GC?
Yeah, it doesn't make sense that a type of x, y, z should be a
class. I would stay with a struct here.
Ali
Sorry I am a bit disappointed. It seems writeln itself will check
if the struct to be printed has toString. If not, it use default
struct printer.
Re: Avoiding GC in D and code consistancy
On 12/30/2017 11:16 PM, Tim Hsu wrote:
> Struct version of Vector3f can't derive toString
> method. writeln() prints unformated struct members. I know I can use
> helper function here. But is there any other way?
The normal way that I know is to insert a function like the following
into Vector3f:
string toString() {
import std.string : format;
return format("%s,%s,%s", x, y, z);
}
> class version of Vector3f. Require new operator in opBinary(). scoped!
> won't work here.
>
> Is there a better to write vector3f class while avoiding GC?
Yeah, it doesn't make sense that a type of x, y, z should be a class. I
would stay with a struct here.
Ali
Avoiding GC in D and code consistancy
I came from C++ looking forward to D. Some languages require
programmers to use GC all the time. However, A lot of time we
don't really need GC especially when the time of destruction is
deterministic in compile time.
I found that struct in D is allocate on stack by default. And we
can use scope! to allocate class on stack too.
See the following code. Struct version of Vector3f can't derive
toString method. writeln() prints unformated struct members. I
know I can use helper function here. But is there any other way?
struct Vector3f {
public:
this(float x, float y, float z) {
this.x = x;
this.y = y;
this.z = z;
}
@property float length2() {
return x*x+y*y+z*z;
}
@property float length() {
import std.math;
return sqrt(x*x+y*y+z*z);
}
Vector3f opBinary(string op)(Vector3f rhs)
{
static if (op == "+") return Vector3f(x+rhs.x, y+rhs.y,
z+rhs.z);
else static if (op == "-") return Vector3f(x-rhs.x,
y-rhs.y, z-rhs.z);
else static assert(0, "Operator "~op~" not implemented");
}
float x, y, z;
}
class version of Vector3f. Require new operator in opBinary().
scoped! won't work here.
Is there a better to write vector3f class while avoiding GC?
Re: Avoiding GC
On Friday, 28 October 2016 at 11:50:20 UTC, hardreset wrote: On Thursday, 27 October 2016 at 07:52:09 UTC, Guillaume Piolat wrote: On Wednesday, 26 October 2016 at 08:18:07 UTC, hardreset wrote: Is there a page somewhere on how to program D without using the GC? The information is scattered. How do I allocate / free structs / classes on the heap manually? Classes => https://github.com/AuburnSounds/dplug/blob/master/core/dplug/core/nogc.d#L122 Thanks. I notice you avoid GC altogether in dplug. Whats the reason for total avoidance as apposed to just avoiding it in the real time code? Not a lot of reason. It's very recent work, I'm still struggling making threadpool works. - Reason #1 was that it gives a way to unload shared libraries on OSX. This bug has been fixed in LDC but would require to make druntime and phobos a shared library to ship. That makes releases 3x larger so I went with disabling the runtime instead (one month of work and still going...). - Reason #2 is that GC does use more memory. Next release of our products use 2x fewer memory. All in all it's _painful_ not to use the D runtime, suddenly you can't use third-party code, and there is no performance enhancement to expect apart from reduced memory usage. Don't avoid the runtime on principles alone.
Re: Avoiding GC
On Thursday, 27 October 2016 at 07:52:09 UTC, Guillaume Piolat wrote: On Wednesday, 26 October 2016 at 08:18:07 UTC, hardreset wrote: Is there a page somewhere on how to program D without using the GC? The information is scattered. How do I allocate / free structs / classes on the heap manually? Classes => https://github.com/AuburnSounds/dplug/blob/master/core/dplug/core/nogc.d#L122 Thanks. I notice you avoid GC altogether in dplug. Whats the reason for total avoidance as apposed to just avoiding it in the real time code?
Re: Avoiding GC
On Wednesday, 26 October 2016 at 08:18:07 UTC, hardreset wrote: Is there a page somewhere on how to program D without using the GC? The information is scattered. How do I allocate / free structs / classes on the heap manually? Classes => https://github.com/AuburnSounds/dplug/blob/master/core/dplug/core/nogc.d#L122 New would be GCed memeory wouldnt it? Yes. Delete is being depreciated? I don't think you ever want delete when there is .destroy
Re: Avoiding GC
On Wednesday, 26 October 2016 at 08:18:07 UTC, hardreset wrote: Is there a page somewhere on how to program D without using the GC? How do I allocate / free structs / classes on the heap manually? New would be GCed memeory wouldnt it? Delete is being depreciated? thanks. There is the following: https://wiki.dlang.org/Memory_Management
Re: Avoiding GC
On Wednesday, 26 October 2016 at 08:18:07 UTC, hardreset wrote: Is there a page somewhere on how to program D without using the GC? How do I allocate / free structs / classes on the heap manually? New would be GCed memeory wouldnt it? Delete is being depreciated? thanks. Probably you want to read: https://dlang.org/phobos/std_experimental_allocator.html Anyway GC works really good for common software development.
Avoiding GC
Is there a page somewhere on how to program D without using the GC? How do I allocate / free structs / classes on the heap manually? New would be GCed memeory wouldnt it? Delete is being depreciated? thanks.
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
Whether s.front uses GC is determined by s.front implementation, caller can't affect it.
Data-Flow (Escape) Analysis to Aid in Avoiding GC
When reading/parsing data from disk often try to write code such
as
foreach (const line; File(filePath).byLine)
{
auto s = line.splitter( )
const x = s.front.to!uint; s.popFront;
const y = s.front.to!double; s.popFront;
...
}
In response to all the discussions regarding performance problems
related to the GC I wonder if there are plans to implement
data-flow analysis in DMD that can detect that the calls to
s.front in the example above doesn't need to use the GC. This
because their references aren't used outside of the foreach scope
(Escape Analysis).
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote: Whether s.front uses GC is determined by s.front implementation, caller can't affect it. I'm talking about internal changes to DMD, in this case.
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 08:21:53 UTC, Per Nordlöw wrote:
When reading/parsing data from disk often try to write code
such as
foreach (const line; File(filePath).byLine)
{
auto s = line.splitter( )
const x = s.front.to!uint; s.popFront;
const y = s.front.to!double; s.popFront;
...
}
In response to all the discussions regarding performance
problems related to the GC I wonder if there are plans to
implement data-flow analysis in DMD that can detect that the
calls to s.front in the example above doesn't need to use the
GC. This because their references aren't used outside of the
foreach scope (Escape Analysis).
I haven't looked into the source, but the only point where this
snippet should allocate is at byLine.
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote: Whether s.front uses GC is determined by s.front implementation, caller can't affect it. Compiling https://github.com/nordlow/justd/blob/master/t_splitter.d with -vgc on dmd git master gives no warnings about GC allocations! Is this really true!?
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 11:34:50 UTC, Per Nordlöw wrote: On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote: Whether s.front uses GC is determined by s.front implementation, caller can't affect it. Compiling https://github.com/nordlow/justd/blob/master/t_splitter.d with -vgc on dmd git master gives no warnings about GC allocations! Is this really true!? Why should splitter.front allocate?
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 13:07:04 UTC, bearophile wrote: I suggest you to read how a marksweep GC works, or better to implement a bare-bones marksweep GC in C language yourself for Lisp-like cons cells, you only need 100 lines of code or so to do it. Got it. Thanks.
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 12:50:14 UTC, Tobias Pankrath wrote: There are no reference counts involved, just simple arithmetic. string a = abc; string b = a[1 .. $]; Then how does the GC know when to release when there are multiple references? Is this because string references immutable storage? Probably -vgc only lists GC allocation inside the current scope and doesn't look inside called functions. For this, there is @nogc. Isn't vgc recursively inferred bottom-up for calls to templates functions?
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 12:40:57 UTC, Per Nordlöw wrote:
On Friday, 13 February 2015 at 11:52:50 UTC, Tobias Pankrath
wrote:
On Friday, 13 February 2015 at 11:34:50 UTC, Per Nordlöw wrote:
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote:
Whether s.front uses GC is determined by s.front
implementation, caller can't affect it.
Compiling
https://github.com/nordlow/justd/blob/master/t_splitter.d
with -vgc on dmd git master gives no warnings about GC
allocations!
Is this really true!?
Why should splitter.front allocate?
Ahh, I think I understand now. I thought that slice creations
ment GC-allocation but it doesn't right? It just increases a
reference counter somewhere and creates a stack context for the
slice right?
There are no reference counts involved, just simple arithmetic.
string a = abc;
string b = a[1 .. $];
struct Slice(T) { T* ptr; size_t length };
Slice!char a = { ptr_to_constant, 3 }
Slice!char b = { a.ptr + 1, 2 }
But what about to!string in
auto x = line.strip.splitter!isWhite.joiner(_).to!string;
?
That needs to allocate.
Probably -vgc only lists GC allocation inside the current scope
and doesn't look inside called functions. For this, there is
@nogc.
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
Per Nordlöw: Then how does the GC know when to release when there are multiple references? The mark phase counts what's reachable and what can't be reached. If an object has one pointer to it, or one hundred pointers, it is not removed. If nothing points to it, it is removed. I suggest you to read how a marksweep GC works, or better to implement a bare-bones marksweep GC in C language yourself for Lisp-like cons cells, you only need 100 lines of code or so to do it. Bye, bearophile
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 12:58:40 UTC, Per Nordlöw wrote: On Friday, 13 February 2015 at 12:50:14 UTC, Tobias Pankrath wrote: There are no reference counts involved, just simple arithmetic. string a = abc; string b = a[1 .. $]; Then how does the GC know when to release when there are multiple references? Is this because string references immutable storage? It scans the memory for pointers to the memory to be freed before freeing them. Isn't vgc recursively inferred bottom-up for calls to templates functions? I didn't know vgc exists until your question, so I don't know what it does exactly. Thought that it will highlight calls to GC.malloc in the current function, even if emitted by the compiler for e.g. closures. I don't think it treats template functions different than other functions (it only considers their signature).
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
Tobias Pankrath: Why should splitter.front allocate? I think that front was able to throw Unicode exceptions, that require the GC. But I think later they have become asserts, that don't require the GC. Bye, bearophile
Re: Data-Flow (Escape) Analysis to Aid in Avoiding GC
On Friday, 13 February 2015 at 11:52:50 UTC, Tobias Pankrath wrote: On Friday, 13 February 2015 at 11:34:50 UTC, Per Nordlöw wrote: On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote: Whether s.front uses GC is determined by s.front implementation, caller can't affect it. Compiling https://github.com/nordlow/justd/blob/master/t_splitter.d with -vgc on dmd git master gives no warnings about GC allocations! Is this really true!? Why should splitter.front allocate? Ahh, I think I understand now. I thought that slice creations ment GC-allocation but it doesn't right? It just increases a reference counter somewhere and creates a stack context for the slice right? But what about to!string in auto x = line.strip.splitter!isWhite.joiner(_).to!string; ?
