Re: dmd 2.063 generated code a lot slower then dmd 2.062
On Tuesday, 15 October 2013 at 06:38:22 UTC, Nick Sabalausky wrote: On Mon, 14 Oct 2013 16:19:23 +0200 Andrej Mitrovic wrote: On 10/14/13, Nick Sabalausky wrote: > And any sane editor There'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. 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.digitalmar...@puremagic.com ie "For reference, that's considerably less than the chrome process that hosts gmail (200mb!)") 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. -- Paulo
Re: dmd 2.063 generated code a lot slower then dmd 2.062
On Mon, 14 Oct 2013 16:19:23 +0200 Andrej Mitrovic wrote: > On 10/14/13, Nick Sabalausky > wrote: > > And any sane editor > > There'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. 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.digitalmar...@puremagic.com ie "For reference, that's considerably less than the chrome process that hosts gmail (200mb!)")
Re: dmd 2.063 generated code a lot slower then dmd 2.062
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 Thaut Visual 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.
Re: dmd 2.063 generated code a lot slower then dmd 2.062
On 10/14/13, Nick Sabalausky wrote: > And any sane editor There'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.
Re: dmd 2.063 generated code a lot slower then dmd 2.062
On Mon, 14 Oct 2013 11:09:54 +0200 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. > 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".)
Re: dmd 2.063 generated code a lot slower then dmd 2.062
Am 14.10.2013 13:30, schrieb Nick Sabalausky: On Mon, 14 Oct 2013 11:09:54 +0200 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. 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".) Visual Studio requests CRLF file endings... But I fully agree CRLF should die. Kind Regards Benjamin Thaut
Re: dmd 2.063 generated code a lot slower then dmd 2.062
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.063 https://github.com/D-Programming-Language/druntime/pull/638
Re: dmd 2.063 generated code a lot slower then dmd 2.062
Am 14.10.2013 11:01, schrieb Walter Bright: On 10/14/2013 1:57 AM, Benjamin Thaut wrote: Am 14.10.2013 10:56, schrieb Walter Bright: 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. 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. I can't reproduce that error, and neither can the autotester. 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 Thaut
Re: dmd 2.063 generated code a lot slower then dmd 2.062
On 10/14/2013 1:57 AM, Benjamin Thaut wrote: Am 14.10.2013 10:56, schrieb Walter Bright: 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. 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. I can't reproduce that error, and neither can the autotester.
Re: dmd 2.063 generated code a lot slower then dmd 2.062
Am 14.10.2013 10:56, schrieb Walter Bright: 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. 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.
Re: dmd 2.063 generated code a lot slower then dmd 2.062
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.
Re: dmd 2.063 generated code a lot slower then dmd 2.062
Am 14.10.2013 09:09, schrieb Walter Bright: 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. 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 Thaut
Re: dmd 2.063 generated code a lot slower then dmd 2.062
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.
