digitalmars.D - Would you trade 0.1% in performance for a better debugging experience?
- 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
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
Nov 17 2014
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.orgShort 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.
Nov 17 2014
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.
Nov 18 2014
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.
Nov 18 2014
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.
Nov 18 2014
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
Nov 18 2014
On Tuesday, 18 November 2014 at 13:18:10 UTC, Steven Schveighoffer wrote:On 11/17/14 6:14 PM, Vladimir Panteleev wrote: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.I proposed to build Phobos and Druntime with stack frames enabled:Sure, why not 3 versions of phobos/runtime in installation? Space is cheap.
Nov 18 2014
On 11/18/14 12:03 PM, Vladimir Panteleev wrote:On Tuesday, 18 November 2014 at 13:18:10 UTC, 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.On 11/17/14 6:14 PM, Vladimir Panteleev wrote: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 proposed to build Phobos and Druntime with stack frames enabled:Sure, why not 3 versions of phobos/runtime in installation? Space is cheap.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
Nov 18 2014
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
Nov 18 2014
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.htmlWe 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=7044That 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.
Dec 04 2014
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.
Nov 18 2014
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
Nov 18 2014
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).
Nov 18 2014
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:Is it fair if I argue that fixing DWARF info generation is a better solution then?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-L478I 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
Nov 18 2014
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).
Nov 18 2014
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: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? -- MarcoIs 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.
Nov 18 2014
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.
Nov 19 2014
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:I don't know if segfaults were ever in the picture. Vladimir was talking about InvalidMemoryOperationErrors thrown by the runtime. -- MarcoIs 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.
Nov 21 2014
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
Dec 04 2014
On Thursday, 4 December 2014 at 22:08:20 UTC, Martin Nowak wrote:-fasynchronous-unwind-tablesWhoa! Are they big?
Dec 05 2014
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-L478If it's able to throw exceptions, it means code dealing with DWARF is already used.
Nov 19 2014
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.
Dec 04 2014
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
Dec 04 2014
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.
Nov 18 2014
I am personally willing to pay the small performance cost for better debugging information.
Nov 19 2014
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.
Nov 19 2014
I think it is a better default, at least in absence of multiple release flavors.
Dec 04 2014
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.
Dec 04 2014
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 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.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.
Dec 04 2014
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.
Dec 04 2014
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.
Dec 05 2014
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.
Dec 04 2014
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.
Dec 05 2014