November 21, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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 |
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | I think it is a better default, at least in absence of multiple release flavors. |
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | 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.
|
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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.
|
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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. |
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 |
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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.
|
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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
|
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | 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.
|
December 04, 2014 Re: Would you trade 0.1% in performance for a better debugging experience? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | 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 |
Copyright © 1999-2021 by the D Language Foundation