dmd commit, revision 663


user: braddr

msg:
Changes to run on win32 under cygwin.

http://www.dsource.org/projects/dmd/changeset/663

On 9/6/2010 11:25 PM, dsource.org wrote:
> dmd commit, revision 663
> 
> 
> user: braddr
> 
> msg:
> Changes to run on win32 under cygwin.
> 
> http://www.dsource.org/projects/dmd/changeset/663
> 

The test suite that is.. not the compiler, though that'd be a rather interesting project all by itself. :)

So far, I've only tested the quick version on win32.  The time it takes to run just that subset under windows/cygwin is embarassingly slow (3 minutes on linux vs 18 minutes on windows -- not exactly the same hardware, but close enough). I've been focused on 'get it runnable' and have deferred the speed issues.  But 18 minutes is unacceptably slow, imho.  I don't want to think about how long it'd take to run every argument combination.

My plan at this point is to replace the makefile+do_test.sh with a c++ or d executable.  I'm tempted to use D, but that introduces a bootstrapping concern as well as a reliability concern.

I've enabled the dmd tests in the win32 auto-tester, so those results will start showing up hourly now too.

Later,
Brad

dsource.org wrote:
> dmd commit, revision 663
>
>
> user: braddr
>
> msg:
> Changes to run on win32 under cygwin.
>
> http://www.dsource.org/projects/dmd/changeset/663
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
> 
Thanks. With replacing diff with "diff --strip-trailing-cr", it also works with MSys. I don't know whether this option is also available elsewhere, though.

You can get rid of the map files in the test directory by adding "-map nul.map" to the dmd command line.

There are 3 test cases that take very long to execute: testaa, testhread2 and testgc3. I have not even seen the latter finish before I got impatient and killed the process. I'd say these actually do not test the compiler, but the library, so maybe the pass counts could be reduced. Are these test way faster on linux?

Rainer

Rainer Schuetze wrote:
>
> There are 3 test cases that take very long to execute: testaa, testhread2 and testgc3. I have not even seen the latter finish before I got impatient and killed the process. I'd say these actually do not test the compiler, but the library, so maybe the pass counts could be reduced. Are these test way faster on linux?
>

testgc3, the longest running of the 3, takes 27 seconds on my Windows machine.

On 7 September 2010 09:03, Brad Roberts <braddr at puremagic.com> wrote:
> On 9/6/2010 11:25 PM, dsource.org wrote:
>> dmd commit, revision 663
>>
>>
>> user: braddr
>>
>> msg:
>> Changes to run on win32 under cygwin.
>>
>> http://www.dsource.org/projects/dmd/changeset/663
>>
>
> The test suite that is.. not the compiler, though that'd be a rather interesting project all by itself. :)
>
> So far, I've only tested the quick version on win32. ?The time it takes to run just that subset under windows/cygwin is embarassingly slow (3 minutes on linux vs 18 minutes on windows -- not exactly the same hardware, but close enough). I've been focused on 'get it runnable' and have deferred the speed issues. ?But 18 minutes is unacceptably slow, imho. ?I don't want to think about how long it'd take to run every argument combination.
>
> My plan at this point is to replace the makefile+do_test.sh with a c++ or d executable. ?I'm tempted to use D, but that introduces a bootstrapping concern as well as a reliability concern.

I think we should be dogfooding as much as we can. Also, we could do some more interesting things with a D test program.

> I've enabled the dmd tests in the win32 auto-tester, so those results will start showing up hourly now too.

I get this:

Running runnable tests
gnumake[1]: *** No rule to make target `test_results/runnable/A16.d.out', needed
 by `run_runnable_tests'.  Stop.
gnumake: *** [start_runnable_tests] Error 2

(gnumake is just cygwin make, renamed). Any ideas?

On 9/7/2010 12:51 AM, Walter Bright wrote:
> 
> 
> Rainer Schuetze wrote:
>>
>> There are 3 test cases that take very long to execute: testaa, testhread2 and testgc3. I have not even seen the latter finish before I got impatient and killed the process. I'd say these actually do not test the compiler, but the library, so maybe the pass counts could be reduced. Are these test way faster on linux?
>>
> 
> testgc3, the longest running of the 3, takes 27 seconds on my Windows machine.

Takes 31 seconds on my linux box.. roughly the same.  There are several tests that are much closer to phobos or druntime tests than dmd tests.  I'm sure they are ancient and predate the meaningful separation of the three.  But it's also, generally, not worth quibbling about where exactly they live, still take time to execute no matter where they are and they probably shouldn't just go away.  But I could be convinced otherwise without too much trouble. :)

Rainer, would you be in a good position to time both cygwin and msys on similar hardware?  I don't have the latter installed anywhere.

Later,
Brad

On 9/7/2010 1:02 AM, Don Clugston wrote:
> On 7 September 2010 09:03, Brad Roberts <braddr at puremagic.com> wrote:
>> On 9/6/2010 11:25 PM, dsource.org wrote:
>>> dmd commit, revision 663
>>>
>>>
>>> user: braddr
>>>
>>> msg:
>>> Changes to run on win32 under cygwin.
>>>
>>> http://www.dsource.org/projects/dmd/changeset/663
>>>
>>
>> The test suite that is.. not the compiler, though that'd be a rather interesting project all by itself. :)
>>
>> So far, I've only tested the quick version on win32.  The time it takes to run just that subset under windows/cygwin is embarassingly slow (3 minutes on linux vs 18 minutes on windows -- not exactly the same hardware, but close enough). I've been focused on 'get it runnable' and have deferred the speed issues.  But 18 minutes is unacceptably slow, imho.  I don't want to think about how long it'd take to run every argument combination.
>>
>> My plan at this point is to replace the makefile+do_test.sh with a c++ or d executable.  I'm tempted to use D, but that introduces a bootstrapping concern as well as a reliability concern.
> 
> I think we should be dogfooding as much as we can. Also, we could do some more interesting things with a D test program.

I agree, but I still worry about using a D app when the compiler itself should be suspect at that stage of life.

>> I've enabled the dmd tests in the win32 auto-tester, so those results will start showing up hourly now too.
> 
> I get this:
> 
> Running runnable tests
> gnumake[1]: *** No rule to make target `test_results/runnable/A16.d.out', needed
>  by `run_runnable_tests'.  Stop.
> gnumake: *** [start_runnable_tests] Error 2
> 
> (gnumake is just cygwin make, renamed). Any ideas?

I remember seeing that early on in my development.  I _think_ it's because it's not finding the dmd executable.  Try this debugging step.  In the Makefile, after the block of code doing OS detection, right after the export OS line, add this:

$(error os: $(OS))

I suspect it's detecting the OS badly and setting DMD to ../src/dmd which doesn't exist.

Thanks,
Brad

On 9/7/2010 12:18 AM, Rainer Schuetze wrote:
> dsource.org wrote:
>> dmd commit, revision 663
>>
>>
>> user: braddr
>>
>> msg:
>> Changes to run on win32 under cygwin.
>>
>> http://www.dsource.org/projects/dmd/changeset/663
>> 
> Thanks. With replacing diff with "diff --strip-trailing-cr", it also works with MSys. I don't know whether this option is also available elsewhere, though.

Yes, the gnu diff (which is what linux and cygwin use) supports --strip-trailing-cr, which would be a more specific arg than -w to use.  Does msys not support -w?  Which diff is failing as is?

> You can get rid of the map files in the test directory by adding "-map nul.map" to the dmd command line.

Hrm.. see also the bug I filed earlier today:
   http://d.puremagic.com/issues/show_bug.cgi?id=4833

I couldn't decide if I wanted to consider it a bug that the map file is being generated without being asked for or not.  Either way, it's yet another inconsistency between linux and windows that should be considered for cleanup at some point.  I'll add -map nul to the test suite since it certainly isn't adding value there and is littering the wrong directory with map droppings.

Thanks,
Brad

Brad Roberts wrote:
> On 9/7/2010 12:51 AM, Walter Bright wrote:
> 
>> Rainer Schuetze wrote:
>> 
>>> There are 3 test cases that take very long to execute: testaa, testhread2 and testgc3. I have not even seen the latter finish before I got impatient and killed the process. I'd say these actually do not test the compiler, but the library, so maybe the pass counts could be reduced. Are these test way faster on linux?
>>>
>>> 
>> testgc3, the longest running of the 3, takes 27 seconds on my Windows machine.
>> 
>
> Takes 31 seconds on my linux box.. roughly the same.  There are several tests that are much closer to phobos or druntime tests than dmd tests.  I'm sure they are ancient and predate the meaningful separation of the three.  But it's also, generally, not worth quibbling about where exactly they live, still take time to execute no matter where they are and they probably shouldn't just go away.  But I could be convinced otherwise without too much trouble. :)
>
> 
Ouch, there was still some extra checking in my version of aaa.d in druntime, causing the slowdown. Without it, testgc3 now terminates well before 30s. Sorry for the noise.

> Rainer, would you be in a good position to time both cygwin and msys on similar hardware?  I don't have the latter installed anywhere.
>
> 
I have a desktop and a laptop, both with Core2Duo 2GHz, but the latter a mobile version. The desktop has cygwin* installed (just updated the 5 year old version), while the laptop is running msys. Building "make -i quick" took 7min28 with cygwin and 8:20 with msys. So I don't see a considerable difference in speed for the installations.

Both runs showed average CPU usage of only 10% most of the time (i.e. 20% of one core). Both systems have rather fast disks (raptor vs ssd), so my guess is that the excessive process spawning (2-3 bash instances per test) causes the bad performance.

Rainer

(*) running these tests caused other problems due to cr/lf pairs: the shell would not execute scripts with CR in them, so I had to convert the *.sh files. Maybe these should not have svn:eol-style native set, but LF.

> Later,
> Brad
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
> 

>> Thanks. With replacing diff with "diff --strip-trailing-cr", it also works with
>> MSys. I don't know whether this option is also available elsewhere, though.
>> 
>
> Yes, the gnu diff (which is what linux and cygwin use) supports --strip-trailing-cr, which would be a more specific arg than -w to use.  Does msys not support -w?  Which diff is failing as is?
>
> 
Msys supports -w, but I just took the option with the least changes to the files to compare.

With the latest test suite, the failing files are in scripts a20-postscript.sh, json-postscript.sh and cov2-postscript.sh (plus a few messages about files that cannot be removed), but I haven't checked, why.