Re: [boost] Results of Cray SV1 regression tests

From: Matthias Troyer (troyer_at_[hidden])
Date: 2003-02-05 04:27:30

On Wednesday, February 5, 2003, at 12:55 AM, Beman Dawes wrote:

> At 05:06 PM 2/4/2003, Matthias Troyer wrote:
>
> >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.

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 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.
>
> 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.

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.

> 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