On Wednesday, February 5, 2003, at 12:55 AM, Beman Dawes wrote:
At 05:06 PM 2/4/2003, Matthias Troyer wrote:Sure, I can post them once we have taken care of these nits, and I checked through the tests that failed due to linking errors.
>I have run the regression tests on a Cray SV1 system using the Cray C++
>3.6 compiler and posted the results on
>http://www.comp-phys.org/boost/cs-sn9626.html
Why don't you consider posting the results on SourceForge with the other results? It would be nice to use something that included "cray" rather than "sn9626" in the file names, and we ought to tweak the config to better identify the platform and compiler, but those are just nits.
I took a look, and quite a few of the failures are tests that also have trouble on other compilers. Hopefully some of these will pass in the next week or two as we get ready for the release. There are probably have a few configuration issues to be worked out, but really it isn't a bad showing for a first try.Please let me know when I should run another regression test. Now that everything is set up they should not take more than a day to run.
config_info is reporting the compiler as using the EDG front-end, but not identifying the library. Whose copyrights are on the headers?
It is a modified version of the Dinkumware library. The copyrights are:
/* COPYRIGHT CRAY RESEARCH, INC. * UNPUBLISHED -- ALL RIGHTS RESERVED UNDER * THE COPYRIGHT LAWS OF THE UNITED STATES */
As far as the filesystem library goes, the two run errors detected are really minor; the implementation seems to be reporting one error code differently from other POSIX systems, and it is allowing remove on a directory that is not empty. I can fix both of those problems if you can tell me some macro name that uniquely identifies Cray C++ (because the same problems aren't showing on other POSIX platforms.)It seems that on all Crays the macros CRAY and cray are defined. If one wants to be machine specific, we got this information recently:
On Wednesday, January 22, 2003, at 05:58 PM, Dan Gohman wrote:
On the Cray T3D, Cray T3E, and Cray SV1, _CRAYT3D, _CRAYT3E, and _CRAYSV1 are defined.Until I get access to one of the new X1 machines and can test the differences I would propose to just use the CRAY or cray macro.
On the Cray X1, __crayx1 is defined, short is 16 bits (don't use it for int_fast16_t, though), int is 32 bits, and long is 64 bits.
Thanks for sharing your results! Most of us will never see a Cray, let alone test on one.For those who want to see a Cray: the old X-MP we used in the early nineties now functions as a bench in the entrance hall of our computing center at ETH :-).
I had used Crays a lot a decade ago, but moved to massively parallel systems in the past seven years. Now, the the advent of the Cray X1 massively parallel machine with vector CPUS (in my opinion probably as a US response to the Japanese Earth Simulator), vector computing has become fashionable again and we are digging out our old vectorization skills. Since also the compilers are now better standard conforming, I am porting my codes back to the Crays.
After we get the regrssion tests to work, there will be a special challenge for ublas or MTL-3: Calling the BLAS routine where appropriate will be essential in getting any decent performance on these types of CPUs. Does anybody know what the progress is on calling BLAS from ublas where appropriate?
Matthias
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
