Could people please give me the output of the command:


/usr/sbin/psrinfo -pv | fgrep UltraSPARC

on a machine, and tell me what the machine is.


There is some code in the ATLAS maths library which does this:

       if (!CmndOneLine(NULL, "/usr/sbin/psrinfo -pv | fgrep 
UltraSPARC", res))
       {
          if (strstr(res, "UltraSPARC-IV"))
             mach = SunUSIV;
          else if (strstr(res, "UltraSPARC-III"))
             mach = SunUSIII;
          else if (strstr(res, "UltraSPARC-II"))
             mach = SunUSII;
          else if (strstr(res, "UltraSPARC-I"))
             mach = SunUSI;
       }

I would like to extend that, so cover other processors.

On a T5240 I have access to, I see:


/usr/sbin/psrinfo -pv | fgrep UltraSPARC
   UltraSPARC-T2+ (chipid 0, clock 1167 MHz)
   UltraSPARC-T2+ (chipid 1, clock 1167 MHz)


but can anyone else tell me what they get on other machines? I suspect 
'T1' and 'T2' without the plus sign might be possible, but I don't 
actually know.

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:
> Could people please give me the output of the command:
> 
> 
> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
> 
> on a machine, and tell me what the machine is.


I'd like this for Solaris x86 machines too, if someone can grep the 
processor type. Obviously it wont be UltarSPARC in that case.

Dave

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:
> Dave wrote:
>> Could people please give me the output of the command:
>>
>>
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>
>> on a machine, and tell me what the machine is.
> 
> 
> I'd like this for Solaris x86 machines too, if someone can grep the 
> processor type. Obviously it wont be UltarSPARC in that case.
> 
> Dave
> 

sunblok_#  uname -a
SunOS sunblok 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-5_10


sunblok_# /usr/sbin/psrinfo -pv | fgrep UltraSPARC
/usr/sbin/psrinfo: illegal option -- p
usage:
         psrinfo [-v] [processor_id ...]
         psrinfo -s processor_id

Dave wrote:
> Dave wrote:
>> Could people please give me the output of the command:
>>
>>
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>
>> on a machine, and tell me what the machine is.
> 
> 
> I'd like this for Solaris x86 machines too, if someone can grep the 
> processor type. Obviously it wont be UltarSPARC in that case.
> 
> Dave
> 
sunblok_#  uname -a
SunOS sunblok 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-5_10


sunblok_# /usr/sbin/psrinfo -pv | fgrep UltraSPARC
/usr/sbin/psrinfo: illegal option -- p
usage:
         psrinfo [-v] [processor_id ...]
         psrinfo -s processor_id

On 2009-07-22 13:30:29 +0100, Dave <foo@coo.com> said:

> I would like to extend that, so cover other processors.
> 
> On a T5240 I have access to, I see:
> 
> 
> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>    UltraSPARC-T2+ (chipid 0, clock 1167 MHz)
>    UltraSPARC-T2+ (chipid 1, clock 1167 MHz)
> 
> 
> but can anyone else tell me what they get on other machines? I suspect 
> 'T1' and 'T2' without the plus sign might be possible, but I don't 
> actually know.

On our T1000s and T2000 running Solaris 10 I get:

  UltraSPARC-T1 (cpuid 0 clock 1000 MHz)

Nice and slow :-)

-- 
Chris

Dave wrote:
> Dave wrote:
>> Could people please give me the output of the command:
>>
>>
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>
>> on a machine, and tell me what the machine is.
> 
> 
> I'd like this for Solaris x86 machines too, if someone can grep the 
> processor type. Obviously it wont be UltarSPARC in that case.
> 
> Dave
> 



# /usr/sbin/psrinfo -pv
The physical processor has 2 virtual processors (0 1)
   x86 (GenuineIntel 6FB family 6 model 15 step 11 clock 2992 MHz)
	Intel(r) Core(tm)2 Duo CPU     E6850  @ 3.00GHz
#

Dave wrote:
> Dave wrote:
>> Could people please give me the output of the command:
>>
>>
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>
>> on a machine, and tell me what the machine is.
> 
> 
> I'd like this for Solaris x86 machines too, if someone can grep the 
> processor type. Obviously it wont be UltarSPARC in that case.

For the two I have at hand:

$ /usr/sbin/psrinfo -pv
The physical processor has 2 virtual processors (0 1)
   x86 (AuthenticAMD 20F32 family 15 model 35 step 2 clock 2211 MHz)
         AMD Athlon(tm) 64 X2 Dual Core Processor 4400+


$ /usr/sbin/psrinfo -pv
The physical processor has 1 virtual processor (0)
   x86 (AuthenticAMD 20F42 family 15 model 36 step 2 clock 1990 MHz)
	AMD Turion(tm) 64 Mobile Technology ML-37

Richard B. Gilbert wrote:
> Dave wrote:
>> Dave wrote:
>>> Could people please give me the output of the command:
>>>
>>>
>>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>>
>>> on a machine, and tell me what the machine is.
>>
>>
>> I'd like this for Solaris x86 machines too, if someone can grep the 
>> processor type. Obviously it wont be UltarSPARC in that case.
>>
>> Dave
>>
> 
> sunblok_#  uname -a
> SunOS sunblok 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-5_10
> 
> 
> sunblok_# /usr/sbin/psrinfo -pv | fgrep UltraSPARC
> /usr/sbin/psrinfo: illegal option -- p
> usage:
>         psrinfo [-v] [processor_id ...]
>         psrinfo -s processor_id

Thank you. Obvious '-p' has been added in 9 or 10.

Is there any way you can get the processor type on that machine

For my own purposes, we are only intending supporting S10 or 11, but I 
was hoping to passs the mods back up to the ATLAS developer, so he can 
add support for later CPUs. That's going to need some work, if the 
command he uses (/usr/sbin/psrinfo -pv) does not work on Solaris 8.


-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Chris Ridd wrote:
> On 2009-07-22 13:30:29 +0100, Dave <foo@coo.com> said:
> 
>> I would like to extend that, so cover other processors.
>>
>> On a T5240 I have access to, I see:
>>
>>
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>    UltraSPARC-T2+ (chipid 0, clock 1167 MHz)
>>    UltraSPARC-T2+ (chipid 1, clock 1167 MHz)
>>
>>
>> but can anyone else tell me what they get on other machines? I suspect 
>> 'T1' and 'T2' without the plus sign might be possible, but I don't 
>> actually know.
> 
> On our T1000s and T2000 running Solaris 10 I get:
> 
>  UltraSPARC-T1 (cpuid 0 clock 1000 MHz)


Thank you.

That was particularly what I was looking for. I guess there will be a T2 
too. a T3 is in development I'm aware of that, if some Sun blogs are 
anything to go by.

> Nice and slow :-)

Yes, these CoolThreads don't work too well for some applications. My 
Blade 2000 (1200 MHz) is a *lot* quicker than the 1167 MHz T5240 for 
most of what I'm doing with these machines.

But the T5240 leaves my blade well behind on some well written 
multi-threaded code.

Andrew Gabriel posted some multi-threaded code
http://groups.google.co.uk/group/comp.unix.solaris/browse_thread/thread/7041af61bab6cfd/718b4fb647765119?hl=en&ie=UTF-8&q=Single-threaded+T5240+performance&pli=1
for computing the prime less than n. The performance on the T2 was 
excellent.

We do in fact have an algorithm for computing prime_pi() which is much 
more sophisticated that the one used in that example code Andrew posted. 
  It should leave Mathematica for dead, and when converted into 
multi-threaded, will be even quicker.

PS, if you are reading this Andrew, I noticed your comment about the use 
of FORTRAN style variables in C code in that thread above.

I once knew a PhD student whose variables were all Disney characters!! I 
tried helping here debug her code, but it is almost impossible when 
lengths are variables like Snoopy, an attenuation coefficient is Sleepy, 
the scattering coefficient might be Snow_White etc.

(Sorry Louise, in the unlikely event you are reading this, but your use 
of variables names were 'unique'. )






-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Thommy M. wrote:
> Dave wrote:
>> Dave wrote:
>>> Could people please give me the output of the command:
>>>
>>>
>>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>>
>>> on a machine, and tell me what the machine is.
>>
>>
>> I'd like this for Solaris x86 machines too, if someone can grep the 
>> processor type. Obviously it wont be UltarSPARC in that case.
> 
> For the two I have at hand:
> 
> $ /usr/sbin/psrinfo -pv
> The physical processor has 2 virtual processors (0 1)
>   x86 (AuthenticAMD 20F32 family 15 model 35 step 2 clock 2211 MHz)
>         AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
> 
> 
> $ /usr/sbin/psrinfo -pv
> The physical processor has 1 virtual processor (0)
>   x86 (AuthenticAMD 20F42 family 15 model 36 step 2 clock 1990 MHz)
>     AMD Turion(tm) 64 Mobile Technology ML-37


Thank you very much. I need to work out if the ATLAS code uses the same 
bit of code for x86 as it does sparc, but these are useful to known

Does anyone have access to a machine running a T2, but not a T2+ 
processor? I'd particularly like to know what that gives, although I can 
take a pretty good guess.

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave <foo@coo.com> wrote:
> Dave wrote:
>> Could people please give me the output of the command:
>> 
>> 
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>> 
>> on a machine, and tell me what the machine is.
> 
> 
> I'd like this for Solaris x86 machines too, if someone can grep the 
> processor type. Obviously it wont be UltarSPARC in that case.
> 
> Dave
 
# psrinfo -pv
The physical processor has 4 virtual processors (0-3)
  x86 (chipid 0x0 GenuineIntel family 6 model 23 step 6 clock 2500 MHz)
        Intel(r) Xeon(r) CPU           L5420  @ 2.50GHz


-- 
Jim Pennino

Remove .spam.sux to reply.

Dave wrote:
> Chris Ridd wrote:
>> On 2009-07-22 13:30:29 +0100, Dave <foo@coo.com> said:
>>
>>> I would like to extend that, so cover other processors.
>>>
>>> On a T5240 I have access to, I see:
>>>
>>>
>>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>>    UltraSPARC-T2+ (chipid 0, clock 1167 MHz)
>>>    UltraSPARC-T2+ (chipid 1, clock 1167 MHz)
>>>
>>>
>>> but can anyone else tell me what they get on other machines? I 
>>> suspect 'T1' and 'T2' without the plus sign might be possible, but I 
>>> don't actually know.
>>
>> On our T1000s and T2000 running Solaris 10 I get:
>>
>>  UltraSPARC-T1 (cpuid 0 clock 1000 MHz)
> 
> 
> Thank you.
> 
> That was particularly what I was looking for. I guess there will be a T2 
> too. a T3 is in development I'm aware of that, if some Sun blogs are 
> anything to go by.
> 
>> Nice and slow :-)
> 
> Yes, these CoolThreads don't work too well for some applications. My 
> Blade 2000 (1200 MHz) is a *lot* quicker than the 1167 MHz T5240 for 
> most of what I'm doing with these machines.
> 
> But the T5240 leaves my blade well behind on some well written 
> multi-threaded code.
> 
> Andrew Gabriel posted some multi-threaded code
> http://groups.google.co.uk/group/comp.unix.solaris/browse_thread/thread/7041af61bab6cfd/718b4fb647765119?hl=en&ie=UTF-8&q=Single-threaded+T5240+performance&pli=1 
> 
> for computing the prime less than n. The performance on the T2 was 
> excellent.
> 
> We do in fact have an algorithm for computing prime_pi() which is much 
> more sophisticated that the one used in that example code Andrew posted. 
>  It should leave Mathematica for dead, and when converted into 
> multi-threaded, will be even quicker.
> 
> PS, if you are reading this Andrew, I noticed your comment about the use 
> of FORTRAN style variables in C code in that thread above.
> 
> I once knew a PhD student whose variables were all Disney characters!! I 
> tried helping here debug her code, but it is almost impossible when 
> lengths are variables like Snoopy, an attenuation coefficient is Sleepy, 
> the scattering coefficient might be Snow_White etc.
> 
> (Sorry Louise, in the unlikely event you are reading this, but your use 
> of variables names were 'unique'. )
> 

I used to work with graduate students at Princeton.  Most of them hadn't 
a clue about computers.  Not surprising in the early 1980s; computers of 
any sort cost more than I made in several years.  If not for IBM's 
generosity even Princeton would have had trouble affording them.

I tried to teach "The Art of Computer Programming" with varying degrees 
of success.  Among the hardest things to teach were the idea that 
variable names should be selected for clarity; e.g. you wrote "PRESSURE" 
instead of "XYZZY".  Equally difficult was the idea that anyone else 
might need to be able to read and understand their code.  Inevitably the 
students moved on and someone new had to figure out what they had been 
doing and continue or modify/improve/continue.

On 2009-07-22 16:14:45 +0100, Dave <foo@coo.com> said:

> Chris Ridd wrote:
>> On 2009-07-22 13:30:29 +0100, Dave <foo@coo.com> said:
>> 
>>> I would like to extend that, so cover other processors.
>>> 
>>> On a T5240 I have access to, I see:
>>> 
>>> 
>>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>>>    UltraSPARC-T2+ (chipid 0, clock 1167 MHz)
>>>    UltraSPARC-T2+ (chipid 1, clock 1167 MHz)
>>> 
>>> 
>>> but can anyone else tell me what they get on other machines? I suspect 
>>> 'T1' and 'T2' without the plus sign might be possible, but I don't 
>>> actually know.
>> 
>> On our T1000s and T2000 running Solaris 10 I get:
>> 
>>  UltraSPARC-T1 (cpuid 0 clock 1000 MHz)
> 
> 
> Thank you.
> 
> That was particularly what I was looking for. I guess there will be a 
> T2 too. a T3 is in development I'm aware of that, if some Sun blogs are 
> anything to go by.

The number of threads makes up for it a bit...

I didn't quite get how atlas uses the results, but it feels like it 
might be better to try and munge the output of isainfo/isalist than 
psrinfo. Check the man pages for what flags to use.

> I once knew a PhD student whose variables were all Disney characters!! 
> I tried helping here debug her code, but it is almost impossible when 
> lengths are variables like Snoopy, an attenuation coefficient is 
> Sleepy, the scattering coefficient might be Snow_White etc.

This is possibly apocryphal, but I heard of an electrical engineer who 
#defined K in their C code just so they could write things like "10K" 
in their program... :-(

-- 
Chris

Richard B. Gilbert wrote:
> Dave wrote:

>> I once knew a PhD student whose variables were all Disney characters!! 
>> I tried helping here debug her code, but it is almost impossible when 
>> lengths are variables like Snoopy, an attenuation coefficient is 
>> Sleepy, the scattering coefficient might be Snow_White etc.
>>
>> (Sorry Louise, in the unlikely event you are reading this, but your 
>> use of variables names were 'unique'. )
>>
> 
> I used to work with graduate students at Princeton.  Most of them hadn't 
> a clue about computers.  Not surprising in the early 1980s; computers of 
> any sort cost more than I made in several years.  If not for IBM's 
> generosity even Princeton would have had trouble affording them.

I got my PhD in 1999 - I think she got hers about the same time. So not 
as early, and computers were a lot more common then.

> I tried to teach "The Art of Computer Programming" with varying degrees 
> of success.  Among the hardest things to teach were the idea that 
> variable names should be selected for clarity; e.g. you wrote "PRESSURE" 
> instead of "XYZZY".  Equally difficult was the idea that anyone else 
> might need to be able to read and understand their code.  Inevitably the 
> students moved on and someone new had to figure out what they had been 
> doing and continue or modify/improve/continue.

It's a bit silly to use names like that. I would have thought it was 
common sence not to.

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Chris Ridd wrote:

>>>  UltraSPARC-T1 (cpuid 0 clock 1000 MHz)
>>
>>
>> Thank you.
>>
>> That was particularly what I was looking for. I guess there will be a 
>> T2 too. a T3 is in development I'm aware of that, if some Sun blogs 
>> are anything to go by.
> 
> The number of threads makes up for it a bit...
> 
> I didn't quite get how atlas uses the results, but it feels like it 
> might be better to try and munge the output of isainfo/isalist than 
> psrinfo. Check the man pages for what flags to use.

ATLAS is a linear algebra library which is very CPU intensive. To get 
best peformance, the installation tunes various parameters to reduce the 
executation time. That tuning process is taking 8.5 hours on the T5240.

It's possible to reduce this dramatically, but having a set of default 
tuning parameters for any particular archititecture.

http://math-atlas.sourceforge.net/faq.html#ArchDef

I want to add support for the T1, T2, T2+, T3 (in development) and will 
take a guess there might be a T3+, T4 and T4+. If the latter processors 
never exist, it's only a few bytes wasted.

Once that is done, I can generate tuning parameters once on the T2+ and 
reduce the build time of ATLAS considerably.

The defaults will change with compiler version, speed of processor etc, 
but having a set that is half-reasonable will be useful.

You are probably right about using other techniques. I suspect the ATLAS 
develpers are not Solaris gurus and do not have access to all SPARC 
systems. (One at least does have access to the T5240 I used).


>> I once knew a PhD student whose variables were all Disney characters!! 
>> I tried helping here debug her code, but it is almost impossible when 
>> lengths are variables like Snoopy, an attenuation coefficient is 
>> Sleepy, the scattering coefficient might be Snow_White etc.
> 
> This is possibly apocryphal, but I heard of an electrical engineer who 
> #defined K in their C code just so they could write things like "10K" in 
> their program... :-(

There's an example in K+R where an Algol programmer could write Algol 
and the C compiler accept it, given a set of #define's. Each to their 
own I guess.



-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:
> Richard B. Gilbert wrote:
>> Dave wrote:
> 
>>> I once knew a PhD student whose variables were all Disney 
>>> characters!! I tried helping here debug her code, but it is almost 
>>> impossible when lengths are variables like Snoopy, an attenuation 
>>> coefficient is Sleepy, the scattering coefficient might be Snow_White 
>>> etc.
>>>
>>> (Sorry Louise, in the unlikely event you are reading this, but your 
>>> use of variables names were 'unique'. )
>>>
>>
>> I used to work with graduate students at Princeton.  Most of them 
>> hadn't a clue about computers.  Not surprising in the early 1980s; 
>> computers of any sort cost more than I made in several years.  If not 
>> for IBM's generosity even Princeton would have had trouble affording 
>> them.
> 
> I got my PhD in 1999 - I think she got hers about the same time. So not 
> as early, and computers were a lot more common then.
> 
>> I tried to teach "The Art of Computer Programming" with varying 
>> degrees of success.  Among the hardest things to teach were the idea 
>> that variable names should be selected for clarity; e.g. you wrote 
>> "PRESSURE" instead of "XYZZY".  Equally difficult was the idea that 
>> anyone else might need to be able to read and understand their code.  
>> Inevitably the students moved on and someone new had to figure out 
>> what they had been doing and continue or modify/improve/continue.
> 
> It's a bit silly to use names like that. I would have thought it was 
> common sence not to.
> 

Common sense is a rare commodity!

On 2009-07-22 18:50:04 +0100, Dave <foo@coo.com> said:

> I want to add support for the T1, T2, T2+, T3 (in development) and will 
> take a guess there might be a T3+, T4 and T4+. If the latter processors 
> never exist, it's only a few bytes wasted.
> 
> Once that is done, I can generate tuning parameters once on the T2+ and 
> reduce the build time of ATLAS considerably.
> 
> The defaults will change with compiler version, speed of processor etc, 
> but having a set that is half-reasonable will be useful.
> 
> You are probably right about using other techniques. I suspect the 
> ATLAS develpers are not Solaris gurus and do not have access to all 
> SPARC systems. (One at least does have access to the T5240 I used).

Nod. It just seems more useful to check for CPU features 
(isainfo/isalist) rather than CPU names (psrinfo). But this is probably 
down the list after actually getting the thing to build at all :-)

How do they cope with x86 chips with their variety of CPU extensions 
and SSE versions?
-- 
Chris

On Wed, 22 Jul 2009 18:40:11 +0100
Dave <foo@coo.com> wrote:

> It's a bit silly to use names like that. I would have thought it was 
> common sence not to.

It's called common sense because it's so darn uncommon.

-- 
Stefaan A Eeckels
-- 
When the need is strong, there are those who will believe anything.
                                                    -- Arnold Lobel

Chris Ridd wrote:
> On 2009-07-22 18:50:04 +0100, Dave <foo@coo.com> said:
> 
>> I want to add support for the T1, T2, T2+, T3 (in development) and 
>> will take a guess there might be a T3+, T4 and T4+. If the latter 
>> processors never exist, it's only a few bytes wasted.
>>
>> Once that is done, I can generate tuning parameters once on the T2+ 
>> and reduce the build time of ATLAS considerably.
>>
>> The defaults will change with compiler version, speed of processor 
>> etc, but having a set that is half-reasonable will be useful.
>>
>> You are probably right about using other techniques. I suspect the 
>> ATLAS develpers are not Solaris gurus and do not have access to all 
>> SPARC systems. (One at least does have access to the T5240 I used).
> 
> Nod. It just seems more useful to check for CPU features 
> (isainfo/isalist) rather than CPU names (psrinfo). But this is probably 
> down the list after actually getting the thing to build at all :-)

ATLAS does build, but it is only one of about 100 components of Sage.

The problem is the length of time ATLAS takes to build + tune. ATLAS is 
probably taking 40% of the total build time. (8.5 hours for ATLAS on a 
T5240). It takes a bit less on my Blade 2000 to build ATLAS (probably 
4-5 hours). It should be possible to reduce both dramatically by 
avoiding all this tuning.

There is an issue with ATLAS dumping core on the T5240, the reason for 
which we don't know, but we have a work-around. (Basically return a 
sensible default for one of the parameters, rather than try to get an 
optmised value, which results in a core dump).

ATLAS build fines on my Blade 2000 - it just takes many hours to do so.

> How do they cope with x86 chips with their variety of CPU extensions and 
> SSE versions?

There is particular code written for particular processors for Linux. I 
don't think there is much at all done for Solaris on x86, but I am not 
sure.

There's currently no native windows port of Sage, though Microsoft are 
sponsoring one.

My main interest is in the SPARC port of Sage. The OpenSolaris is 
another issue, and I will address, but SPARC is my main priority. If I 
can cut the build time of ATLAS a lot, quicker progress can be made on 
other issues. Hence despite the fact ATLAS build, and other things like 
ecl (lisp interpreter do not), I'd like to resolve the ATLAS issues first.



-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:
> I once knew a PhD student whose variables were all Disney characters!! I 
> tried helping here debug her code, but it is almost impossible when 
> lengths are variables like Snoopy, an attenuation coefficient is Sleepy, 
> the scattering coefficient might be Snow_White etc.

When I was teaching maintenance of a sonar system with an embedded 
computer, I found in the schematics, that a button I had been taught 
does nothing actually had a wire back to an interrupt input.

I asked the manufacturer's rep what that did, and he didn't know but 
showed me where the assembly language source for the system was stored.

The jump labels looked like the graphics in the old Batman TV series:
Biff
Bang
Pow
boom
crash
etc.

I showed it to the rep.  "Oh, that must be Bob's code.
He's not with us any more."

-- 
Wes Groleau

    You're all individuals!
           Yes, we're all individuals!
    You're all different!
           Yes, we are all different!
                                I'm not!
                      ("Life of Brian")

Dave wrote:
>> This is possibly apocryphal, but I heard of an electrical engineer who 
>> #defined K in their C code just so they could write things like "10K" 
>> in their program... :-(

In a language where a Duration of 1.0 is one second, it can be
VERY useful to declare

    Minute : constant Duration := 60.0;
    Hour   : constant Duration := 60.0 * Minute;
    Day    : constant Duration := 24.0 8 Hour;

> There's an example in K+R where an Algol programmer could write Algol 
> and the C compiler accept it, given a set of #define's. Each to their 
> own I guess.

I once had to look at a system where the programmers had heard of the
DoD "Ada mandate" but were not aware of how easy it was to get a waiver
when the situation justified.

So they wrote an Ada package containing subprograms which you could
insert into LISP to make it acceptable to an Ada compiler yet
still have it resemble the original LISP.

And another group that wrote a pre-processor that translated straight
LISP into functionally equivalent Ada.

Sorry, guys, you are developing in LISP, not Ada.  Without a waiver,
the so-called mandate said DEVELOP in Ada, not develop in LISP and
convert to Ada.

-- 
Wes Groleau

   Daily lessons & activities & their assessment
   http://Ideas.Lang-Learn.us/barrett?itemid=1413

On Jul 22, 10:30=A0pm, Dave <f...@coo.com> wrote:
> Could people please give me the output of the command:
>
> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
> I would like to extend that, so cover other processors.

UltraSPARC-IIIi ... on a V240 and V440
UltraSPARC-III+ ... on a V480 and 280R
UltraSPARC-IIe ... on a SunBlade 150, Netra X1 and SunFire V100
UltraSPARC-IIi ... on an Ultra5

All these should already be covered by the tests for UltraSPARC-II and
UltraSPARC-III that you listed (unless you need to differentiate
between, for example, a III, III+ and a IIIi).

David Wilson wrote:
> On Jul 22, 10:30 pm, Dave <f...@coo.com> wrote:
>> Could people please give me the output of the command:
>>
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>> I would like to extend that, so cover other processors.
> 
> UltraSPARC-IIIi ... on a V240 and V440
> UltraSPARC-III+ ... on a V480 and 280R
> UltraSPARC-IIe ... on a SunBlade 150, Netra X1 and SunFire V100
> UltraSPARC-IIi ... on an Ultra5
> 
> All these should already be covered by the tests for UltraSPARC-II and
> UltraSPARC-III that you listed (unless you need to differentiate
> between, for example, a III, III+ and a IIIi).


Thank you. Currently the tests don't differentiate these, but there 
might be some advantage to doing so. I'll discuss this with the main 
ATLAS developer.

My immediate aim is to make the changes necessary to get ATLAS to build 
in a reasonable time on the T5240. For that, I will make patches for 
ATLAS inside Sage. I suspect the ATLAS developer will integrate my 
patches for the newer processors once I've added the changes and 
supplied him with the tuning data for at least a T2+.

He might be more reluctant to change code which has been tested for a 
number of years, especially as we wont have the tuning data. Gathering 
the data takes a long time and I don't have access to machines with all 
these processors. I've personally got access to a Sun Ultra 60, Ultra 
80, Blade 2000, Blade 2500 and T5240.

UltraSPARC-II   .. Ultra 60 (Ultra 80 should be the same)
UltraSPARC-III+ .. Blade 2000
UltraSPARC-T2+  .. T5240

I don't know the output from a Blade 2500, but I can get that.

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

Dave wrote:

> ATLAS is a linear algebra library which is very CPU intensive. To get 
> best peformance, the installation tunes various parameters to reduce the 
> executation time. That tuning process is taking 8.5 hours on the T5240.
> 


why doesn't use Sunperf (free available in sun studio tools) instead of 
Atlas on (open)solaris systems?
on my sun v40z, i got:
% psrinfo -pv
The physical processor has 1 virtual processor (0)
   x86 (AuthenticAMD family 15 model 5 step 10 clock 2192 MHz)
         AMD Opteron(tm) Processor 848
The physical processor has 1 virtual processor (1)
   x86 (AuthenticAMD family 15 model 5 step 10 clock 2192 MHz)
         AMD Opteron(tm) Processor 848
The physical processor has 1 virtual processor (2)
   x86 (AuthenticAMD family 15 model 5 step 10 clock 2192 MHz)
         AMD Opteron(tm) Processor 848
The physical processor has 1 virtual processor (3)
   x86 (AuthenticAMD family 15 model 5 step 10 clock 2192 MHz)
         AMD Opteron(tm) Processor 848

and
% isainfo
amd64 i386
% isalist
amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

and my laptop:
$ psrinfo -pv
The physical processor has 1 virtual processor (0)
   x86 (GenuineIntel 6D8 family 6 model 13 step 8 clock 1733 MHz)
         Intel(r) Pentium(r) M processor 1.73GHz
$ isainfo
i386
$ isalist
pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

hth,

gerard

jdh13 wrote:
> Dave wrote:
> 
>> ATLAS is a linear algebra library which is very CPU intensive. To get 
>> best peformance, the installation tunes various parameters to reduce 
>> the executation time. That tuning process is taking 8.5 hours on the 
>> T5240.
>>
> 
> 
> why doesn't use Sunperf (free available in sun studio tools) instead of 
> Atlas on (open)solaris systems?


The code in Sage is aimed to be portable across many systems (M$ are 
paying for a port to Windoze for example). Hence it's much preferable 
for us to use the ATLAS code.

dave

-- 
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange'  take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.

btw, rather than using system() try sysinfo()

For example, to pull the platform:

        char larch[0x100];

        if (sysinfo(SI_PLATFORM, larch, sizeof(larch)) > 0)
                /* it worked */

larch will then contain a string like "SUNW,Sun-Fire-V210"

There are also SI_ISALIST, SI_MACHINE and various SI_ARCHITECTURE
ones..

T6340

Same as your T5240

Sun V210

The physical processor has 1 virtual processor (0)
  UltraSPARC-IIIi (portid 0 impl 0x16 ver 0x34 clock 1336 MHz)
The physical processor has 1 virtual processor (1)
  UltraSPARC-IIIi (portid 1 impl 0x16 ver 0x34 clock 1336 MHz)

Sun V100

The physical processor has 1 virtual processor (0)
  UltraSPARC-IIe (portid 0 impl 0x13 ver 0x33 clock 548 MHz)

Dell PE

The physical processor has 4 virtual processors (0 2 4 6)
  x86 (chipid 0x0 GenuineIntel family 6 model 23 step 6 clock 2333
MHz)
        Intel(r) Xeon(r) CPU           E5410  @ 2.33GHz
The physical processor has 4 virtual processors (1 3 5 7)
  x86 (chipid 0x1 GenuineIntel family 6 model 23 step 6 clock 2333
MHz)
        Intel(r) Xeon(r) CPU           E5410  @ 2.33GHz

On Jul 22, 1:30=A0pm, Dave <f...@coo.com> wrote:
> Could people please give me the output of the command:
>
> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>
> on a machine, and tell me what the machine is.
>
> There is some code in the ATLAS maths library which does this:
>
> =A0 =A0 =A0 =A0if (!CmndOneLine(NULL, "/usr/sbin/psrinfo -pv | fgrep
> UltraSPARC", res))
> =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 if (strstr(res, "UltraSPARC-IV"))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0mach =3D SunUSIV;
> =A0 =A0 =A0 =A0 =A0 else if (strstr(res, "UltraSPARC-III"))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0mach =3D SunUSIII;
> =A0 =A0 =A0 =A0 =A0 else if (strstr(res, "UltraSPARC-II"))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0mach =3D SunUSII;
> =A0 =A0 =A0 =A0 =A0 else if (strstr(res, "UltraSPARC-I"))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0mach =3D SunUSI;
> =A0 =A0 =A0 =A0}
>
> I would like to extend that, so cover other processors.
>
> On a T5240 I have access to, I see:
>
> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
> =A0 =A0UltraSPARC-T2+ (chipid 0, clock 1167 MHz)
> =A0 =A0UltraSPARC-T2+ (chipid 1, clock 1167 MHz)
>
> but can anyone else tell me what they get on other machines? I suspect
> 'T1' and 'T2' without the plus sign might be possible, but I don't
> actually know.
>
> --
> I respectfully request that this message is not archived by companies as
> unscrupulous as 'Experts Exchange' . In case you are unaware,
> 'Experts Exchange' =A0take questions posted on the web and try to find
> idiots stupid enough to pay for the answers, which were posted freely
> by others. They are leeches.

# uname -a
SunOS psun-gt-dor-1 5.10 Generic_127127-11 sun4v sparc
SUNW,Sun-Fire-T200
# psrinfo -pv
The physical processor has 32 virtual processors (0-31)
  UltraSPARC-T1 (cpuid 0 clock 1400 MHz)
#

root@sun-cs-dor-2 # uname -a
SunOS sun-cs-dor-2 5.9 Generic_117171-15 sun4u sparc
SUNW,Sun-Fire-V490
root@sun-cs-dor-2 #  psrinfo -pv
The UltraSPARC-IV physical processor has 2 virtual processors (0, 16)
The UltraSPARC-IV physical processor has 2 virtual processors (1, 17)
The UltraSPARC-IV physical processor has 2 virtual processors (2, 18)
The UltraSPARC-IV physical processor has 2 virtual processors (3, 19)
root@sun-cs-dor-2 #

/usr/platform/`uname -i`/sbin/prtdiag -v
System Configuration: Sun Microsystems  sun4u Sun Fire V1280
System clock frequency: 150 MHZ
Memory size: 24GB

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CPUs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
                    E$         CPU     CPU       Temperature
Fan
 CPU     Freq      Size        Impl.   Mask     Die    Ambient   Speed
Unit
 ------  --------  ----------  ------  ----  --------  --------  -----
----
 SB0/P0  1200 MHz  8MB         US-III+  6.0     44 C      26 C
 SB0/P1  1200 MHz  8MB         US-III+  6.0     44 C      25 C
 SB0/P2  1200 MHz  8MB         US-III+  6.0     42 C      25 C
 SB0/P3  1200 MHz  8MB         US-III+  6.0     42 C      26 C
 SB2/P0  1200 MHz  8MB         US-III+  6.0     41 C      25 C
 SB2/P1  1200 MHz  8MB         US-III+  6.0     41 C      25 C
 SB2/P2  1200 MHz  8MB         US-III+  6.0     43 C      26 C
 SB2/P3  1200 MHz  8MB         US-III+  6.0     43 C      27 C
 SB4/P0  1200 MHz  8MB         US-III+  6.0     41 C      26 C
 SB4/P1  1200 MHz  8MB         US-III+  6.0     42 C      27 C
 SB4/P2  1200 MHz  8MB         US-III+  6.0     44 C      27 C
 SB4/P3  1200 MHz  8MB         US-III+  6.0     42 C      26 C

Regards

Jeremy

On Wed, 22 Jul 2009 13:33:33 +0100, Dave <foo@coo.com> wrote:

>Dave wrote:
>> Could people please give me the output of the command:
>> 
>> 
>> /usr/sbin/psrinfo -pv | fgrep UltraSPARC
>> 
>> on a machine, and tell me what the machine is.
>
>
>I'd like this for Solaris x86 machines too, if someone can grep the 
>processor type. Obviously it wont be UltarSPARC in that case.

Solaris SXCE snv_115 in VirtualBox 3.0.2 on top of Windows Vista
on an Acer Aspire 9420 notebook:

2009-07-30T21:45:59 sa@ozon3 ~ $ uname -a
SunOS ozon3 5.11 snv_115 i86pc i386 i86pc

2009-07-30T21:47:30 sa@ozon3 ~ $ /usr/sbin/psrinfo -pv
The physical processor has 1 virtual processor (0)
  x86 (GenuineIntel 6F6 family 6 model 15 step 6 clock 1650 MHz)
        Intel(r) Core(tm)2 CPU         T5500  @ 1.66GHz


>Dave
-- 
   )  Kees
  (
c[_]    The only difference between a cult and a religion is
        the amount of real estate they own.
     -- Frank Zappa [#483]

Dave <foo@coo.com> writes:

> I'd like this for Solaris x86 machines too, if someone can grep the
> processor type. Obviously it wont be UltarSPARC in that case.

In the x86-based machines the processor type can vary, as can be
seen in the X4200 examples below.

Supermicro X7DB8:

The physical processor has 4 virtual processors (0 2 4 6)
  x86 (chipid 0x0 GenuineIntel family 6 model 15 step 7 clock 2667 MHz)
        Intel(r) Xeon(r) CPU           X5355  @ 2.66GHz
The physical processor has 4 virtual processors (1 3 5 7)
  x86 (chipid 0x1 GenuineIntel family 6 model 15 step 7 clock 2667 MHz)
        Intel(r) Xeon(r) CPU           X5355  @ 2.66GHz

X4200:

The physical processor has 2 virtual processors (0 1)
  x86 (chipid 0x0 AuthenticAMD family 15 model 65 step 2 clock 2793 MHz)
        Dual-Core AMD Opteron(tm) Processor 2220 SE
The physical processor has 2 virtual processors (2 3)
  x86 (chipid 0x1 AuthenticAMD family 15 model 65 step 2 clock 2793 MHz)
        Dual-Core AMD Opteron(tm) Processor 2220 SE

another X4200:

The physical processor has 2 virtual processors (0 1)
  x86 (chipid 0x0 AuthenticAMD family 15 model 33 step 2 clock 2593 MHz)
        Dual Core AMD Opteron(tm) Processor 285 SE
The physical processor has 2 virtual processors (2 3)
  x86 (chipid 0x1 AuthenticAMD family 15 model 33 step 2 clock 2593 MHz)
        Dual Core AMD Opteron(tm) Processor 285 SE

X4500:

The physical processor has 2 virtual processors (0 1)
  x86 (chipid 0x0 AuthenticAMD family 15 model 33 step 2 clock 2593 MHz)
        Dual Core AMD Opteron(tm) Processor 285
The physical processor has 2 virtual processors (2 3)
  x86 (chipid 0x1 AuthenticAMD family 15 model 33 step 2 clock 2593 MHz)
        Dual Core AMD Opteron(tm) Processor 285

X4150:

The physical processor has 4 virtual processors (0 2 4 6)
  x86 (chipid 0x0 GenuineIntel family 6 model 23 step 6 clock 2826 MHz)
        Intel(r) Xeon(r) CPU           E5440  @ 2.83GHz
The physical processor has 4 virtual processors (1 3 5 7)
  x86 (chipid 0x1 GenuineIntel family 6 model 23 step 6 clock 2826 MHz)
        Intel(r) Xeon(r) CPU           E5440  @ 2.83GHz

X4250:

The physical processor has 4 virtual processors (0 2 4 6)
  x86 (chipid 0x0 GenuineIntel family 6 model 23 step 6 clock 2992 MHz)
        Intel(r) Xeon(r) CPU           E5450  @ 3.00GHz
The physical processor has 4 virtual processors (1 3 5 7)
  x86 (chipid 0x1 GenuineIntel family 6 model 23 step 6 clock 2992 MHz)
        Intel(r) Xeon(r) CPU           E5450  @ 3.00GHz

X4270:

The physical processor has 8 virtual processors (0-3 8-11)
  x86 (chipid 0x0 GenuineIntel family 6 model 26 step 5 clock 2267 MHz)
        Intel(r) Xeon(r) CPU           E5520  @ 2.27GHz
The physical processor has 8 virtual processors (4-7 12-15)
  x86 (chipid 0x1 GenuineIntel family 6 model 26 step 5 clock 2267 MHz)
        Intel(r) Xeon(r) CPU           E5520  @ 2.27GHz

X4600:

The physical processor has 2 virtual processors (0 1)
  x86 (chipid 0x0 AuthenticAMD family 15 model 33 step 2 clock 2613 MHz)
        Dual Core AMD Opteron(tm) Processor 885
The physical processor has 2 virtual processors (2 3)
  x86 (chipid 0x1 AuthenticAMD family 15 model 33 step 2 clock 2613 MHz)
        Dual Core AMD Opteron(tm) Processor 885
The physical processor has 2 virtual processors (4 5)
  x86 (chipid 0x2 AuthenticAMD family 15 model 33 step 2 clock 2613 MHz)
        Dual Core AMD Opteron(tm) Processor 885
The physical processor has 2 virtual processors (6 7)
  x86 (chipid 0x3 AuthenticAMD family 15 model 33 step 2 clock 2613 MHz)
        Dual Core AMD Opteron(tm) Processor 885

-- 
The only "intuitive" interface is the nipple. After that, it's all
learned.                         -- Bruce Ediger on X interfaces