digitalmars.D - dmd 2.063 generated code a lot slower then dmd 2.062
- Benjamin Thaut (6/6) Oct 13 2013 I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code
- Walter Bright (2/6) Oct 14 2013 Not aware of any such changes.
- Benjamin Thaut (13/21) Oct 14 2013 I actually found it. I havily use core.sys.windows.stacktrace in my code...
- Walter Bright (2/7) Oct 14 2013 It means it isn't a correct 32 bit object file.
- Benjamin Thaut (3/13) Oct 14 2013 And what could cause this? I already tried manually deleting everything
- Walter Bright (2/17) Oct 14 2013 I can't reproduce that error, and neither can the autotester.
- Benjamin Thaut (8/27) Oct 14 2013 I found it: src\rt\minit.obj is corrupt. When I copy the file from the
- Nick Sabalausky (16/24) Oct 14 2013 Automatic line ending conversions need to be nuked from existence.
- Benjamin Thaut (5/29) Oct 14 2013 Visual Studio requests CRLF file endings...
- Michal Minich (6/10) Oct 14 2013 Visual Studio (at least 2010) keeps whatever original CR / LF or
- Andrej Mitrovic (4/5) Oct 14 2013 There's your problem right there. I'd say a sane diff view would make
- Nick Sabalausky (10/17) Oct 14 2013 Github's entire web frontend is horrible. They don't even know how to
- PauloPinto (9/32) Oct 15 2013 Sadly that is the future. :(
- Benjamin Thaut (2/7) Oct 14 2013 https://github.com/D-Programming-Language/druntime/pull/638
I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd 2.063.2 generates in debug mode is significantly slower then the code generated by dmd 2.062. Have there been changes to the debug mode that affect execution speed? Like additional debug checks? Kind Regards Benjamin Thaut
Oct 13 2013
On 10/13/2013 11:29 PM, Benjamin Thaut wrote:I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd 2.063.2 generates in debug mode is significantly slower then the code generated by dmd 2.062. Have there been changes to the debug mode that affect execution speed? Like additional debug checks?Not aware of any such changes.
Oct 14 2013
Am 14.10.2013 09:09, schrieb Walter Bright:On 10/13/2013 11:29 PM, Benjamin Thaut wrote:I actually found it. I havily use core.sys.windows.stacktrace in my code and I did make some modifications on my druntime branch which I accidentially reverted when merging in druntime 2.063.2 These changes make stacktracing on windows faster by a factor of 10. Thats why I see such a performance impact with dmd 2.063 I'm currently preparing a pull request for this but I ran into an issue. When compiling the latest druntime with the latest dmd for windows 32-bit I get the following error message: lib\druntime.lib: Error: corrupt object module On windows 64-bit everything works fine. Any ideas why this happens? Kind Regards Benjamin ThautI just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd 2.063.2 generates in debug mode is significantly slower then the code generated by dmd 2.062. Have there been changes to the debug mode that affect execution speed? Like additional debug checks?Not aware of any such changes.
Oct 14 2013
On 10/14/2013 12:24 AM, Benjamin Thaut wrote:When compiling the latest druntime with the latest dmd for windows 32-bit I get the following error message: lib\druntime.lib: Error: corrupt object module On windows 64-bit everything works fine. Any ideas why this happens?It means it isn't a correct 32 bit object file.
Oct 14 2013
Am 14.10.2013 10:56, schrieb Walter Bright:On 10/14/2013 12:24 AM, Benjamin Thaut wrote:And what could cause this? I already tried manually deleting everything thats not checked into git. "make -f win32.mak clean" doesn't help either.When compiling the latest druntime with the latest dmd for windows 32-bit I get the following error message: lib\druntime.lib: Error: corrupt object module On windows 64-bit everything works fine. Any ideas why this happens?It means it isn't a correct 32 bit object file.
Oct 14 2013
On 10/14/2013 1:57 AM, Benjamin Thaut wrote:Am 14.10.2013 10:56, schrieb Walter Bright:I can't reproduce that error, and neither can the autotester.On 10/14/2013 12:24 AM, Benjamin Thaut wrote:And what could cause this? I already tried manually deleting everything thats not checked into git. "make -f win32.mak clean" doesn't help either.When compiling the latest druntime with the latest dmd for windows 32-bit I get the following error message: lib\druntime.lib: Error: corrupt object module On windows 64-bit everything works fine. Any ideas why this happens?It means it isn't a correct 32 bit object file.
Oct 14 2013
Am 14.10.2013 11:01, schrieb Walter Bright:On 10/14/2013 1:57 AM, Benjamin Thaut wrote:I found it: src\rt\minit.obj is corrupt. When I copy the file from the 2.064 beta package it builds sucessfully. Might have to do something with the line ending settings in git. Maybe a .gitattributes file setting *.obj to binary should be added to the druntime repository to prevent issues like this. Kind Regards Benjamin ThautAm 14.10.2013 10:56, schrieb Walter Bright:I can't reproduce that error, and neither can the autotester.On 10/14/2013 12:24 AM, Benjamin Thaut wrote:And what could cause this? I already tried manually deleting everything thats not checked into git. "make -f win32.mak clean" doesn't help either.When compiling the latest druntime with the latest dmd for windows 32-bit I get the following error message: lib\druntime.lib: Error: corrupt object module On windows 64-bit everything works fine. Any ideas why this happens?It means it isn't a correct 32 bit object file.
Oct 14 2013
On Mon, 14 Oct 2013 11:09:54 +0200 Benjamin Thaut <code benjamin-thaut.de> wrote:I found it: src\rt\minit.obj is corrupt. When I copy the file from the 2.064 beta package it builds sucessfully. Might have to do something with the line ending settings in git. Maybe a .gitattributes file setting *.obj to binary should be added to the druntime repository to prevent issues like this.Automatic line ending conversions need to be nuked from existence. Git's EOL-conversion "feature" should never have existed in the first place. I can only imagine it happened because some early Git developer must have thought Windows was still stuck in 1991. Or maybe they thought Windows developers write code in notepad. *Any* Git installation that has any form of EOL-conversions enabled is absolutely in error and will eventually just breed problems. And any sane editor will respect the line endings of any file it opens, if it doesn't it's a POS and needs to be fixed/replaced. So there should never be any problem, and never be any need for any of Git's "helpful" automatic data butchering. (Same goes for FTP, but at least FTP has an excuse: It existed back when there *was* such as thing as "Unix line endings" and "Windows line endings".)
Oct 14 2013
Am 14.10.2013 13:30, schrieb Nick Sabalausky:On Mon, 14 Oct 2013 11:09:54 +0200 Benjamin Thaut <code benjamin-thaut.de> wrote:Visual Studio requests CRLF file endings... But I fully agree CRLF should die. Kind Regards Benjamin ThautI found it: src\rt\minit.obj is corrupt. When I copy the file from the 2.064 beta package it builds sucessfully. Might have to do something with the line ending settings in git. Maybe a .gitattributes file setting *.obj to binary should be added to the druntime repository to prevent issues like this.Automatic line ending conversions need to be nuked from existence. Git's EOL-conversion "feature" should never have existed in the first place. I can only imagine it happened because some early Git developer must have thought Windows was still stuck in 1991. Or maybe they thought Windows developers write code in notepad. *Any* Git installation that has any form of EOL-conversions enabled is absolutely in error and will eventually just breed problems. And any sane editor will respect the line endings of any file it opens, if it doesn't it's a POS and needs to be fixed/replaced. So there should never be any problem, and never be any need for any of Git's "helpful" automatic data butchering. (Same goes for FTP, but at least FTP has an excuse: It existed back when there *was* such as thing as "Unix line endings" and "Windows line endings".)
Oct 14 2013
On Monday, 14 October 2013 at 11:34:06 UTC, Benjamin Thaut wrote:Visual Studio requests CRLF file endings... But I fully agree CRLF should die. Kind Regards Benjamin ThautVisual Studio (at least 2010) keeps whatever original CR / LF or CRLF line endings were in file when you opened it. Even warns you when file contains mixed line endings and keeps each line as it were. You can change/normalize them in men File/Advance Save Options.
Oct 14 2013
On 10/14/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:And any sane editorThere's your problem right there. I'd say a sane diff view would make it obvious that CRLF or tabs were injected, and yet github's diff view is a piece of ass.
Oct 14 2013
On Mon, 14 Oct 2013 16:19:23 +0200 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:On 10/14/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:Github's entire web frontend is horrible. They don't even know how to write a freaking web page: http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers (BUt really, I'm not sure there's an ajaxy site in the world that isn't garbage. Ex: http://forum.dlang.org/post/mailman.1442.1379388733.1719.digitalmars-d puremagic.com ie "For reference, that's considerably less than the chrome process that hosts gmail (200mb!)")And any sane editorThere's your problem right there. I'd say a sane diff view would make it obvious that CRLF or tabs were injected, and yet github's diff view is a piece of ass.
Oct 14 2013
On Tuesday, 15 October 2013 at 06:38:22 UTC, Nick Sabalausky wrote:On Mon, 14 Oct 2013 16:19:23 +0200 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:Sadly that is the future. :( I am looking forward that native mobile applications kill these web applications trend, but I am in the minority. And I do write web applications as well, so I do know both sides of the fence. -- PauloOn 10/14/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:Github's entire web frontend is horrible. They don't even know how to write a freaking web page: http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers (BUt really, I'm not sure there's an ajaxy site in the world that isn't garbage. Ex: http://forum.dlang.org/post/mailman.1442.1379388733.1719.digitalmars-d puremagic.com ie "For reference, that's considerably less than the chrome process that hosts gmail (200mb!)")And any sane editorThere's your problem right there. I'd say a sane diff view would make it obvious that CRLF or tabs were injected, and yet github's diff view is a piece of ass.
Oct 15 2013
Am 14.10.2013 09:24, schrieb Benjamin Thaut:I actually found it. I havily use core.sys.windows.stacktrace in my code and I did make some modifications on my druntime branch which I accidentially reverted when merging in druntime 2.063.2 These changes make stacktracing on windows faster by a factor of 10. Thats why I see such a performance impact with dmd 2.063https://github.com/D-Programming-Language/druntime/pull/638
Oct 14 2013