• Vladimir Panteleev (42/42) Nov 17 2014 I proposed to build Phobos and Druntime with stack frames enabled:
• Daniel Kozak via Digitalmars-d (7/63) Nov 17 2014 Short answer: NO.
• deadalnix (3/11) Nov 18 2014 Preferences are not an argument.
• ponce (4/6) Nov 18 2014 Yes, of course. In most programs, a day of work can give >= 1%
• Kagamin (7/7) Nov 18 2014 I'm thinking about 3 configurations:
• Steven Schveighoffer (3/4) Nov 18 2014 Sure, why not 3 versions of phobos/runtime in installation? Space is che...
• Vladimir Panteleev (16/21) Nov 18 2014 You have to consider the combinatorial explosion of our target
• Steven Schveighoffer (8/22) Nov 18 2014 I refuse to let the fact that we package every platform's download into
• Steven Schveighoffer (3/6) Nov 18 2014 Note: I can't imagine the build process for this is simple either.
• Martin Nowak (10/18) Dec 04 2014 We're shifting away from this, there are per-platform zips and
• Logan Capaldo (10/12) Nov 18 2014 This is very much worth it in my opinion. Not just for debugging
• Marco Leise (45/45) Nov 18 2014 Am Mon, 17 Nov 2014 23:14:31 +0000
• Vladimir Panteleev (22/26) Nov 18 2014 Firstly, does DMD generate DWARF debug information in practice
• Marco Leise (21/53) Nov 18 2014 Is it fair if I argue that fixing DWARF info generation is a
• Vladimir Panteleev (8/20) Nov 18 2014 I don't know. Probably. Not all tools may read DWARF info. Also,
• Marco Leise (18/26) Nov 18 2014 Were the tools just not upgraded for amd64 or is there a
• Kagamin (3/5) Nov 19 2014 I'm afraid, DWARF is not designed to unwind segfaults, it works
• Marco Leise (7/13) Nov 21 2014 I don't know if segfaults were ever in the picture. Vladimir
• Martin Nowak (2/4) Dec 04 2014 -fasynchronous-unwind-tables
• Kagamin (2/3) Dec 05 2014 Whoa! Are they big?
• Kagamin (4/13) Nov 19 2014 If it's able to throw exceptions, it means code dealing with
• Martin Nowak (3/5) Dec 04 2014 We're working on that to replace it with more enriched DWARF processing,...
• Martin Nowak (5/10) Dec 04 2014 Agreed we should stick to the platform ABI, then tooling won't be a prob...
• Joakim (16/27) Nov 18 2014 Having run into that error myself on Android/x86
• w0rp (2/2) Nov 19 2014 I am personally willing to pay the small performance cost for
• Rainer Schuetze (20/24) Nov 19 2014 I'm in favor of this change, but wanted to test the effect myself. I ran...
• Dicebot (2/2) Dec 04 2014 I think it is a better default, at least in absence of multiple
• Vladimir Panteleev (8/10) Dec 04 2014 I don't think it's going to happen. The arguments would need to
• Dicebot (5/15) Dec 04 2014 I am not going to fight over this (not _that_ important) but it
• Temtaime (4/4) Dec 04 2014 Why when an DMD developer said « no » to you in ticket you go to
• Sean Kelly (5/9) Dec 05 2014 With stack info in place, core dumps become a much more useful
• Martin Nowak (4/7) Dec 04 2014 If it were only 0.1% at maximum for any code, it wouldn't be a problem.
• Kagamin (3/7) Dec 05 2014 Traditionally it doesn't prevent inlining. Inlined functions will

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

I proposed to build Phobos and Druntime with stack frames enabled:

https://issues.dlang.org/show_bug.cgi?id=13726

Stack frames add three CPU instructions to each function (two in 
the prolog, and one in the epilog). This creates a linked list 
which debuggers, profilers, etc. can easily walk to find which 
function called which. They would allow debugging certain classes 
of bugs much more easily (e.g. the recurring 
InvalidMemoryOperationError - there's a thread about it in 
D.learn just today), and profiling your code with polling 
(non-instrumenting) profilers.

As I understood, in theory, debug information (DWARF and PDB, 
probably not CV) should also contain information allowing an 
accurate stack walk, but it doesn't look like we're currently 
emitting debug information to that level of accuracy. Not all 
debuggers/profilers understand this debug information, either 
(whereas walking the linked list emitted by the stack frames is 
trivial).

We could also start bundling debug builds of Phobos. However, 
these will not help in cases where the performance impact of 
using a full-blown debug build is not acceptable (e.g. if it'll 
skew the profiling results too much, or if you just want readable 
stack frames for your D web service in production).

How much will this cost in performance?

I've run two benchmarks, both show a figure around 0.1%. Many 
performance-sensitive parts of Phobos (std.algorithm) are 
templated and thus are not affected by the Makefile switches. The 
GC is built with -inline, which, although it causes the call 
stack to not contain inlined functions, doesn't cause it to 
abruptly break off like without stack frames.

Is D the first to build its release stdlib with stack frames?

Nope. Microsoft's C release runtime is built stack frames enabled.

Personally, I think the 0.1% is practically negligible 
considering the advantages. My proposal was rejected, so I'd like 
to hear more opinions about this. What do you think?

If you want to run some benchmarks yourself, here are the patches:

https://github.com/CyberShadow/phobos/compare/enable-stack-frames?expand=1
https://github.com/CyberShadow/druntime/compare/enable-stack-frames?expand=1

Or, using Digger:

digger build 
v2.065.0+CyberShadow/phobos/enable-stack-frames+CyberShadow/druntime/enable-stack-frames

Previous discussion from 2012:
http://forum.dlang.org/post/zebqmrhcigfuockcpsfa forum.dlang.org

Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:

Vladimir Panteleev via Digitalmars-d píše v Po 17. 11. 2014 v 23:14
+0000:
 I proposed to build Phobos and Druntime with stack frames enabled:
 
 https://issues.dlang.org/show_bug.cgi?id=13726
 
 Stack frames add three CPU instructions to each function (two in 
 the prolog, and one in the epilog). This creates a linked list 
 which debuggers, profilers, etc. can easily walk to find which 
 function called which. They would allow debugging certain classes 
 of bugs much more easily (e.g. the recurring 
 InvalidMemoryOperationError - there's a thread about it in 
 D.learn just today), and profiling your code with polling 
 (non-instrumenting) profilers.
 
 As I understood, in theory, debug information (DWARF and PDB, 
 probably not CV) should also contain information allowing an 
 accurate stack walk, but it doesn't look like we're currently 
 emitting debug information to that level of accuracy. Not all 
 debuggers/profilers understand this debug information, either 
 (whereas walking the linked list emitted by the stack frames is 
 trivial).
 
 We could also start bundling debug builds of Phobos. However, 
 these will not help in cases where the performance impact of 
 using a full-blown debug build is not acceptable (e.g. if it'll 
 skew the profiling results too much, or if you just want readable 
 stack frames for your D web service in production).
 
 How much will this cost in performance?
 
 I've run two benchmarks, both show a figure around 0.1%. Many 
 performance-sensitive parts of Phobos (std.algorithm) are 
 templated and thus are not affected by the Makefile switches. The 
 GC is built with -inline, which, although it causes the call 
 stack to not contain inlined functions, doesn't cause it to 
 abruptly break off like without stack frames.
 
 Is D the first to build its release stdlib with stack frames?
 
 Nope. Microsoft's C release runtime is built stack frames enabled.
 
 Personally, I think the 0.1% is practically negligible 
 considering the advantages. My proposal was rejected, so I'd like 
 to hear more opinions about this. What do you think?
 
 If you want to run some benchmarks yourself, here are the patches:
 
 https://github.com/CyberShadow/phobos/compare/enable-stack-frames?expand=1
 https://github.com/CyberShadow/druntime/compare/enable-stack-frames?expand=1
 
 Or, using Digger:
 
 digger build 
 v2.065.0+CyberShadow/phobos/enable-stack-frames+CyberShadow/druntime/enable-stack-frames
 
 Previous discussion from 2012:
 http://forum.dlang.org/post/zebqmrhcigfuockcpsfa forum.dlang.org

Short answer: NO.

Long answer:

If I neeed this, I will build version of phobos and druntime myself with
this enabled. Or we could distribute both versions and select one by
some switch. But I am against having stack frames enabled by default.

"deadalnix" <deadalnix gmail.com> writes:

On Tuesday, 18 November 2014 at 07:33:15 UTC, Daniel Kozak via 
Digitalmars-d wrote:
 Short answer: NO.

 Long answer:

 If I neeed this, I will build version of phobos and druntime 
 myself with
 this enabled. Or we could distribute both versions and select 
 one by
 some switch. But I am against having stack frames enabled by 
 default.

Preferences are not an argument.

"ponce" <contact gam3sfrommars.fr> writes:

On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev 
wrote:
 Would you trade 0.1% in performance for a better debugging 
 experience?

Yes, of course. In most programs, a day of work can give >= 1% 
speed-up, and debugging can take many more.

"Kagamin" <spam here.lot> writes:

I'm thinking about 3 configurations:
1. debug
2. release/conservative: assert=off, bounds checks=on, stack 
frames
3. release/optimized: bounds checks=off, no stack frames; can 
also apply additional optimizations for more speed like turning 
assert into assume.

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 11/17/14 6:14 PM, Vladimir Panteleev wrote:
 I proposed to build Phobos and Druntime with stack frames enabled:

Sure, why not 3 versions of phobos/runtime in installation? Space is cheap.

-Steve

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Tuesday, 18 November 2014 at 13:18:10 UTC, Steven 
Schveighoffer wrote:
 On 11/17/14 6:14 PM, Vladimir Panteleev wrote:
 I proposed to build Phobos and Druntime with stack frames 
 enabled:

 Sure, why not 3 versions of phobos/runtime in installation? 
 Space is cheap.

You have to consider the combinatorial explosion of our target 
platforms, and also the impact on the size of the distribution.

- In 2.066.0, phobos.lib is around 9MB.
- *2 for x86/x64.
- *4 for the number of supported platforms.
- *3 for the proposed number of build configurations.

That comes out to over 200 MB. Might be bigger due to debug 
builds of Phobos taking more space.

Compression should reduce the size of the distribution packages, 
but we'd need to move to something other than ZIP files if we 
want to take advantage of similarities between distinct files. 
Perhaps offer .7z as an option.

I'm not against the idea, though enabling stack frames is a much 
simpler change.

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 11/18/14 12:03 PM, Vladimir Panteleev wrote:
 On Tuesday, 18 November 2014 at 13:18:10 UTC, Steven Schveighoffer wrote:
 On 11/17/14 6:14 PM, Vladimir Panteleev wrote:
 I proposed to build Phobos and Druntime with stack frames enabled:

 Sure, why not 3 versions of phobos/runtime in installation? Space is
 cheap.

 You have to consider the combinatorial explosion of our target
 platforms, and also the impact on the size of the distribution.

 - In 2.066.0, phobos.lib is around 9MB.
 - *2 for x86/x64.
 - *4 for the number of supported platforms.
 - *3 for the proposed number of build configurations.

I refuse to let the fact that we package every platform's download into 
one zip to be some sort of argument :) DMD is the only distribution that 
I've ever seen do this.

 That comes out to over 200 MB. Might be bigger due to debug builds of
 Phobos taking more space.

I have 0 problem making the user choose his configuration at download 
time. Each download should be 10MB, possibly x3 for debug and stack 
frame builds.

-Steve

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 11/18/14 1:49 PM, Steven Schveighoffer wrote:

 I refuse to let the fact that we package every platform's download into
 one zip to be some sort of argument :) DMD is the only distribution that
 I've ever seen do this.

Note: I can't imagine the build process for this is simple either.

-Steve

Martin Nowak <code+news.digitalmars dawg.eu> writes:

On 11/18/2014 07:49 PM, Steven Schveighoffer wrote:
 I refuse to let the fact that we package every platform's download into
 one zip to be some sort of argument :) DMD is the only distribution that
 I've ever seen do this.

We're shifting away from this, there are per-platform zips and 
installers now.
See a preview of the new download page.
https://dlang.dawg.eu/download.html

 That comes out to over 200 MB. Might be bigger due to debug builds of
 Phobos taking more space.

 I have 0 problem making the user choose his configuration at download
 time. Each download should be 10MB, possibly x3 for debug and stack
 frame builds.

We could provide additional phobos libraries for downloading.
Problem is, that it's currently fairly hard to switch your phobos library.
There is a plan to improve the config file processing to make such 
things easier.
https://issues.dlang.org/show_bug.cgi?id=7044

"Logan Capaldo" <logancapaldo gmail.com> writes:

On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev 
wrote:
 I proposed to build Phobos and Druntime with stack frames 
 enabled:

This is very much worth it in my opinion. Not just for debugging 
but being able to profile (sometimes in production, without 
needing to recompile with instrumentation or debug symbols), can 
definitely make up for the difference in the long run. Fast, easy 
stack trace taking has a lot of utility, and can be applied where 
loading symbols to do the same makes it too slow to consider. 
Stack traces taken like this can be taken quickly, and symbolized 
later at your leisure offline.

Marco Leise <Marco.Leise gmx.de> writes:

Am Mon, 17 Nov 2014 23:14:31 +0000
schrieb "Vladimir Panteleev" <vladimir thecybershadow.net>:

[=E2=80=A6]

From
http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/

-------------------------------------------------------------

Preserving the base pointer

The base pointer rbp (and its predecessor ebp on x86), being a
stable "anchor" to the beginning of the stack frame throughout
the execution of a function, is very convenient for manual
assembly coding and for debugging [5]. However, some time ago
it was noticed that compiler-generated code doesn't really
need it (the compiler can easily keep track of offsets from
rsp), and the DWARF debugging format provides means (CFI) to
access stack frames without the base pointer.

This is why some compilers started omitting the base pointer
for aggressive optimizations, thus shortening the function
prologue and epilogue, and providing an additional register
for general-purpose use (which, recall, is quite useful on x86
with its limited set of GPRs).

gcc keeps the base pointer by default on x86, but allows the
optimization with the -fomit-frame-pointer compilation flag.
How recommended it is to use this flag is a debated issue -
you may do some googling if this interests you.

Anyhow, one other "novelty" the AMD64 ABI introduced is making
the base pointer explicitly optional, stating:

=C2=BBThe conventional use of %rbp as a frame pointer for the stack
 frame may be avoided by using %rsp (the stack pointer) to
 index into the stack frame. This technique saves two
 instructions in the prologue and epilogue and makes one
 additional general-purpose register (%rbp) available.=C2=AB

gcc adheres to this recommendation and by default omits the
frame pointer on x64, when compiling with optimizations. It
gives an option to preserve it by providing the
-fno-omit-frame-pointer flag. For clarity's sake, the stack
frames showed above were produced without omitting the frame
pointer.

-------------------------------------------------------------

Without fully understanding the issue, omitting the frame
pointer on GNU amd64 systems is the default and is supposed to
work using DWARF debug information. So there should be no need
for a stack frame pointer, right?

Are you mostly concerned with Windows then?

--=20
Marco

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Tuesday, 18 November 2014 at 16:49:55 UTC, Marco Leise wrote:
 Without fully understanding the issue, omitting the frame
 pointer on GNU amd64 systems is the default and is supposed to
 work using DWARF debug information. So there should be no need
 for a stack frame pointer, right?

Firstly, does DMD generate DWARF debug information in practice 
that's correct enough to substitute stack frames? As far as I can 
tell, it doesn't.

Second, there's still the argument that not every debugger and 
profiler can take advantage of the DWARF debug information. It's 
certainly nowhere as easy: from the technical point of view, but 
also from a legal one, considering that (IIRC) most libraries 
dealing with DWARF debug information are GPL or LGPL, meaning we 
can't use them in the D runtime. And indeed, for printing the 
stack trace for an unhandled exception, Druntime currently walks 
the stack frames:

https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L452-L478

There is also the libc backtrace function, which the D runtime 
apparently used at some point:

http://www.gnu.org/software/libc/manual/html_node/Backtraces.html

It was removed in this commit:

https://github.com/D-Programming-Language/druntime/commit/9dca50fe65402fb3cdfbb689f1aca58dc835dce4

The commit message doesn't seem to mention why the use of the 
backtrace function was removed. But from reading the function's 
documentation, it looks like it works in the same way (walking 
the stack frame pointers, i.e. also reliant on stack frames).

Marco Leise <Marco.Leise gmx.de> writes:

Am Tue, 18 Nov 2014 17:15:12 +0000
schrieb "Vladimir Panteleev" <vladimir thecybershadow.net>:

 On Tuesday, 18 November 2014 at 16:49:55 UTC, Marco Leise wrote:
 Without fully understanding the issue, omitting the frame
 pointer on GNU amd64 systems is the default and is supposed to
 work using DWARF debug information. So there should be no need
 for a stack frame pointer, right?

 
 Firstly, does DMD generate DWARF debug information in practice 
 that's correct enough to substitute stack frames? As far as I can 
 tell, it doesn't.

Is it fair if I argue that fixing DWARF info generation is a
better solution then?

 Second, there's still the argument that not every debugger and 
 profiler can take advantage of the DWARF debug information. It's 
 certainly nowhere as easy: from the technical point of view, but 
 also from a legal one, considering that (IIRC) most libraries 
 dealing with DWARF debug information are GPL or LGPL, meaning we 
 can't use them in the D runtime. And indeed, for printing the 
 stack trace for an unhandled exception, Druntime currently walks 
 the stack frames:
 
 https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L452-L478

I don't need to open the link to know the code you linked to.
Ever since I had weird seg faults when an exception was thrown
from my D callback in Gtk code I wondered when this code will
be updated. Consider that "no frame pointers" is the default
for GCC on amd64 and thus practically all libraries on Linux
can't be stack traced by druntime. It needs to use libunwind
in the long run when C++ interfacing becomes more viable and D
programmers start to expect exception handling and stack
traces to work as per system ABI. At least that's what I
believe.

 There is also the libc backtrace function, which the D runtime 
 apparently used at some point:
 
 http://www.gnu.org/software/libc/manual/html_node/Backtraces.html
 
 It was removed in this commit:
 
 https://github.com/D-Programming-Language/druntime/commit/9dca50fe65402fb3cdfbb689f1aca58dc835dce4
 
 The commit message doesn't seem to mention why the use of the 
 backtrace function was removed. But from reading the function's 
 documentation, it looks like it works in the same way (walking 
 the stack frame pointers, i.e. also reliant on stack frames).

It probably fell short when amd64 was introduced. Although
libunwind is not part of the GNU project, it is the de facto
standard on Linux/GNU for stack unwinding with projects like
Mono or perf using it. The license is MIT and it is easy to
make it a runtime dependency of dmd/Phobos packages on Linux.

-- 
Marco

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Tuesday, 18 November 2014 at 18:55:43 UTC, Marco Leise wrote:
 Is it fair if I argue that fixing DWARF info generation is a
 better solution then?

I don't know. Probably. Not all tools may read DWARF info. Also, 
I'm not sure if this is related but Phobos/Druntime are currently 
built without -g, although enabling it should be a much less 
controversial change.

 I don't need to open the link to know the code you linked to.
 Ever since I had weird seg faults when an exception was thrown
 from my D callback in Gtk code I wondered when this code will
 be updated. Consider that "no frame pointers" is the default
 for GCC on amd64 and thus practically all libraries on Linux
 can't be stack traced by druntime. It needs to use libunwind
 in the long run when C++ interfacing becomes more viable and D
 programmers start to expect exception handling and stack
 traces to work as per system ABI. At least that's what I
 believe.

That sounds reasonable. I guess it remains to be seen how much we 
can rely on libunwind (with regards to availability, stability 
and compatibility with DMD-emitted DWARF info).

Marco Leise <Marco.Leise gmx.de> writes:

Am Tue, 18 Nov 2014 19:35:06 +0000
schrieb "Vladimir Panteleev" <vladimir thecybershadow.net>:

 On Tuesday, 18 November 2014 at 18:55:43 UTC, Marco Leise wrote:
 Is it fair if I argue that fixing DWARF info generation is a
 better solution then?

 
 I don't know. Probably. Not all tools may read DWARF info. Also, 
 I'm not sure if this is related but Phobos/Druntime are currently 
 built without -g, although enabling it should be a much less 
 controversial change.

Were the tools just not upgraded for amd64 or is there a
specific reason they require stack frame pointers? How do they
work on 64-bit Linux distributions in general that have no
stack frame pointers? If they are good tools, but never worked
on amd64 reliably, well ... D executables without frame
pointers don't make the situation any worse, right?
Regarding the -g switch, I guess we could call the debug
information that is required for proper exception handling on
Linux "part of the language" and always generate it
independently of the -g switch. Similar to how we currently
require the --export-dynamic linker switch in dmd.conf.
I'm really not knowledgeable about this stuff. Are we trying
to do more here than C++? Does C++ also require DWARF debug
information for stack unwinding?

-- 
Marco

"Kagamin" <spam here.lot> writes:

On Tuesday, 18 November 2014 at 18:55:43 UTC, Marco Leise wrote:
 Is it fair if I argue that fixing DWARF info generation is a
 better solution then?

I'm afraid, DWARF is not designed to unwind segfaults, it works 
only with DWARF exceptions.

Marco Leise <Marco.Leise gmx.de> writes:

Am Wed, 19 Nov 2014 08:14:44 +0000
schrieb "Kagamin" <spam here.lot>:

 On Tuesday, 18 November 2014 at 18:55:43 UTC, Marco Leise wrote:
 Is it fair if I argue that fixing DWARF info generation is a
 better solution then?

 
 I'm afraid, DWARF is not designed to unwind segfaults, it works 
 only with DWARF exceptions.

I don't know if segfaults were ever in the picture. Vladimir
was talking about InvalidMemoryOperationErrors thrown by the
runtime.

-- 
Marco

Martin Nowak <code+news.digitalmars dawg.eu> writes:

On 11/19/2014 09:14 AM, Kagamin wrote:
 I'm afraid, DWARF is not designed to unwind segfaults, it works only
 with DWARF exceptions.

-fasynchronous-unwind-tables

"Kagamin" <spam here.lot> writes:

On Thursday, 4 December 2014 at 22:08:20 UTC, Martin Nowak wrote:
 -fasynchronous-unwind-tables

Whoa! Are they big?

"Kagamin" <spam here.lot> writes:

On Tuesday, 18 November 2014 at 17:15:13 UTC, Vladimir Panteleev 
wrote:
 Second, there's still the argument that not every debugger and 
 profiler can take advantage of the DWARF debug information. 
 It's certainly nowhere as easy: from the technical point of 
 view, but also from a legal one, considering that (IIRC) most 
 libraries dealing with DWARF debug information are GPL or LGPL, 
 meaning we can't use them in the D runtime. And indeed, for 
 printing the stack trace for an unhandled exception, Druntime 
 currently walks the stack frames:

 https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L452-L478

If it's able to throw exceptions, it means code dealing with 
DWARF is already used.

Martin Nowak <code+news.digitalmars dawg.eu> writes:

On 11/18/2014 06:15 PM, Vladimir Panteleev wrote:
 And indeed, for printing the stack trace for an unhandled exception,
 Druntime currently walks the stack frames:

We're working on that to replace it with more enriched DWARF processing, 
e.g. to show line numbers.

Martin Nowak <code+news.digitalmars dawg.eu> writes:

On 11/18/2014 06:00 PM, Marco Leise wrote:
 Without fully understanding the issue, omitting the frame
 pointer on GNU amd64 systems is the default and is supposed to
 work using DWARF debug information. So there should be no need
 for a stack frame pointer, right?

 Are you mostly concerned with Windows then?

Agreed we should stick to the platform ABI, then tooling won't be a problem.
So indeed this seems to be more of a Windows specific problem.

http://msdn.microsoft.com/en-us/library/ms235286.aspx#sectionToggle2
http://msdn.microsoft.com/en-us/library/2kxx5t2c.aspx

"Joakim" <dlang joakim.fea.st> writes:

On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev 
wrote:
 I proposed to build Phobos and Druntime with stack frames 
 enabled:

 https://issues.dlang.org/show_bug.cgi?id=13726

 Stack frames add three CPU instructions to each function (two 
 in the prolog, and one in the epilog). This creates a linked 
 list which debuggers, profilers, etc. can easily walk to find 
 which function called which. They would allow debugging certain 
 classes of bugs much more easily (e.g. the recurring 
 InvalidMemoryOperationError - there's a thread about it in 
 D.learn just today), and profiling your code with polling 
 (non-instrumenting) profilers.

Having run into that error myself on Android/x86 
(https://github.com/D-Programming-Language/druntime/pull/784#iss
ecomment-42768642), 
it would be nice if it was easier to trace.  Losing 0.1% 
performance certainly seems worth it, but you'd think anyone 
tracking such an issue could recompile druntime/phobos 
themselves.  I was unaware that the "-gs" flag would help though, 
and nobody seems to have mentioned it in the forums or github 
until you just did.

I guess the main issue is whether we're sure it doesn't get much 
worse than 0.1%, ie that there aren't degenerate cases where we 
get worse performance declines.  Also, there's the principle of 
whether we want to force a small performance penalty, however 
minute, onto release builds of druntime/phobos for better 
debugging, which is what Walter and Martin seem to be against.

"w0rp" <devw0rp gmail.com> writes:

I am personally willing to pay the small performance cost for 
better debugging information.

Rainer Schuetze <r.sagitario gmx.de> writes:

On 18.11.2014 00:14, Vladimir Panteleev wrote:
 I proposed to build Phobos and Druntime with stack frames enabled:

[...]
 Personally, I think the 0.1% is practically negligible considering the
 advantages. My proposal was rejected, so I'd like to hear more opinions
 about this. What do you think?

I'm in favor of this change, but wanted to test the effect myself. I ran 
the druntime/benchmark tests with and without the -gs option. These 
tests mostly exercise the GC and dynamic and associative array 
implementations. Please note that I'm running a mobile i7 and benchmarks 
can vary quite a bit (average and standard deviation of 5 runs):

Win32 master:     33.8s +- 0.5s
Win32 master -gs: 35.8s +- 0.6s
=>                +5.9%

Being slighlty shocked by the difference, I reran the tests, but without 
a significant different result. Can someone else reproduce this difference?

On Win64 the tests need quite a bit more memory so they get slower, but 
the difference is a lot less:

Win64 master:     46.1s +- 0.8s
Win64 master -gs: 46.3s +- 0.4s
=>                +0.4%

This can be compensated with tiny optimizations, e.g. 
https://github.com/D-Programming-Language/druntime/pull/1027, which are 
lurking everywhere.

"Dicebot" <public dicebot.lv> writes:

I think it is a better default, at least in absence of multiple 
release flavors.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Thursday, 4 December 2014 at 14:28:47 UTC, Dicebot wrote:
 I think it is a better default, at least in absence of multiple 
 release flavors.

I don't think it's going to happen. The arguments would need to 
overrule Walter Bright and Martin Nowak (effectively Druntime's 
current maintainer).

Plus, there's Rainer's benchmark results, which show a different 
figure.

I think I'm going to keep improving Digger instead, to the point 
that the default build flags become of little importance.

"Dicebot" <public dicebot.lv> writes:

On Thursday, 4 December 2014 at 14:39:07 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 4 December 2014 at 14:28:47 UTC, Dicebot wrote:
 I think it is a better default, at least in absence of 
 multiple release flavors.

 I don't think it's going to happen. The arguments would need to 
 overrule Walter Bright and Martin Nowak (effectively Druntime's 
 current maintainer).

 Plus, there's Rainer's benchmark results, which show a 
 different figure.

 I think I'm going to keep improving Digger instead, to the 
 point that the default build flags become of little importance.

I am not going to fight over this (not _that_ important) but it 
is a sad mistake. Providing plesant out of the box experience is 
more important that perfect out of the box performance.

"Temtaime" <temtaime gmail.com> writes:

Why when an DMD developer said « no » to you in ticket you go to 
the forum and troll there ?
If one wants debug information he will use debug version of 
phobos. In fine-tune application there's no need for -gs flag.

"Sean Kelly" <sean invisibleduck.org> writes:

On Thursday, 4 December 2014 at 16:44:51 UTC, Temtaime wrote:
 Why when an DMD developer said « no » to you in ticket you go 
 to the forum and troll there ?
 If one wants debug information he will use debug version of 
 phobos. In fine-tune application there's no need for -gs flag.

With stack info in place, core dumps become a much more useful 
tool for diagnosing production problems.  It should definitely be 
an option that can be disabled, but I'm in favor of having it on 
by default.

Martin Nowak <code+news.digitalmars dawg.eu> writes:

On 11/18/2014 12:14 AM, Vladimir Panteleev wrote:
 Personally, I think the 0.1% is practically negligible considering the
 advantages. My proposal was rejected, so I'd like to hear more opinions
 about this. What do you think?

If it were only 0.1% at maximum for any code, it wouldn't be a problem.
But enabling stack traces would make a std.simd module which would only 
consists of tiny leaf functions basically unusable.

"Kagamin" <spam here.lot> writes:

On Thursday, 4 December 2014 at 22:11:36 UTC, Martin Nowak wrote:
 If it were only 0.1% at maximum for any code, it wouldn't be a 
 problem.
 But enabling stack traces would make a std.simd module which 
 would only consists of tiny leaf functions basically unusable.

Traditionally it doesn't prevent inlining. Inlined functions will 
disappear from the stack trace, but most of it will stay.