Re: [boost] test_read_write_mutex trouble under Tru64 Unix
--- "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> wrote:
--- "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> wrote:
Last night I started Aleksey's regression.py script under Tru64 Unix. It used to finish after 6 hours, but now the test_read_write_mutex process has consumed 16 CPU hours already without finishing. I am going to kill it. I hope the failure shows up at the meta-comm site. Let me know if more information is required.
I had to use the kill command a few more times. I don't think the results made it to the meta-comm server. The output of regression.py is available here:
http://cci.lbl.gov/~rwgk/tmp/tru64cxx65_boost_regression/
The file name is run_2004_08_18_0207.log. The file run_regression.csh was used to start the tests.
For the record: the tests are still broken. I just had to kill -INT the "process_jam_log" process after 75 minutes of CPU time. Before that I already killed -INT two mutex-related tests. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
Ralf W. Grosse-Kunstleve wrote:
For the record: the tests are still broken. I just had to kill -INT the "process_jam_log" process after 75 minutes of CPU time. Before that I already killed -INT two mutex-related tests.
I believe process_jam_log would eventually have finished, I you would have been patient enough. (Maybe next year or so... :-) ) I checked in a performance patch for process_jam_log yesterday, do you know if your version already has that patch included? AFAICT, the patch is not enough to let process_jam_log complete in a reasonable amount of time on that platform for a full regression run, but I got a fives times speed-up when processing smaller parts of the regression log file. The workaround I'm currently using is to use a binary built by g++-3.4.1, this at least enables me to run the regression tests for that platform. Apart from that, the regression runs for test_read_write_mutex don't hang on my platform currently, they abort with an error. (see http://tinyurl.com/4j7dd ) Markus
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
I believe process_jam_log would eventually have finished, I you would have been patient enough. (Maybe next year or so... :-) )
Oh, I didn't think processing a few log files with a C++ program could take more than 75 minutes?!
I checked in a performance patch for process_jam_log yesterday, do you know if your version already has that patch included?
I was using revision 1.31. A cvs update right now didn't lead to any changes.
AFAICT, the patch is not enough to let process_jam_log complete in a reasonable amount of time on that platform for a full regression run, but I got a fives times speed-up when processing smaller parts of the regression log file.
OK, next time I'll wait a little longer.
The workaround I'm currently using is to use a binary built by g++-3.4.1, this at least enables me to run the regression tests for that platform.
Apart from that, the regression runs for test_read_write_mutex don't hang on my platform currently, they abort with an error. (see http://tinyurl.com/4j7dd )
Hm, if it works better (kind of) for you with the latest compiler maybe I should stop running the tests here... All I care about personally is Boost.Python and that works just fine. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Ralf W. Grosse-Kunstleve wrote:
--- Markus_Schöpflin <markus.schoepflin@comsoft.de> wrote:
I believe process_jam_log would eventually have finished, I you would have been patient enough. (Maybe next year or so... :-) )
Oh, I didn't think processing a few log files with a C++ program could take more than 75 minutes?!
The program appends many single chars to strings in several places and this is a real performance killer in the std library implementation available on this platform. It looks like it does a realloc and copy for every append operation.
I checked in a performance patch for process_jam_log yesterday, do you know if your version already has that patch included?
I was using revision 1.31. A cvs update right now didn't lead to any changes.
That revision has the patch included.
AFAICT, the patch is not enough to let process_jam_log complete in a reasonable amount of time on that platform for a full regression run, but I got a fives times speed-up when processing smaller parts of the regression log file.
OK, next time I'll wait a little longer.
The workaround I'm currently using is to use a binary built by g++-3.4.1, this at least enables me to run the regression tests for that platform.
Apart from that, the regression runs for test_read_write_mutex don't hang on my platform currently, they abort with an error. (see http://tinyurl.com/4j7dd )
Hm, if it works better (kind of) for you with the latest compiler maybe I should stop running the tests here... All I care about personally is Boost.Python and that works just fine.
Which doesn't work at all here. I have a python installation which up to now, I was not able to successfully use with the boost regression runs. Therefore it might make sense if you continue running the regression tests, at least for python. Markus
participants (2)
-
Markus Schöpflin -
Ralf W. Grosse-Kunstleve