http://www.softpanorama.org/Articles/Linux_vs_Solaris/sparc_vs_x86.shtml
>...
>Linux is essentially an OS that flourishes only on Intel. It never achieved
>any significant success on RISC architecture although IBM now is trying to
>change this situation pushing Linux on PowerPC and potentially cannibalizing
>its own AIX sales (at least on low level servers). Actually running several
>competing with each other hardware and software offerings is nothing new for
>IBM.
>Solaris is heterogeneous OS that (unlike Linux) can perform well on two
>architectures: UltraSparc and Intel. Actually Linux used to be more
>heterogeneous in the past when it supported Alpha. But those days are long
>gone.
>...
Marketspeak, I suppose
>5.1. UltraSparc is an expensive but pretty cool CPU :-)
>...
>* Energy efficiency: it consumes less energy then either Intel or Opteron
> and much less then PoewerPC CPUs.
I never heard about "then PoewerPC CPUs", must be something new. :)
>* Fault tolerance. Sun servers can do amazing things with fauly components.
> almost any of them can be switched off. Even low level Sun server like V240
> can survive bam memory chips, onle falty CPU and one burned power supply.
> In some somce it is an cheap cluster.
>* Cleaner architecture. Being big Endean CPU with RISC instruction set
> provides some complier level advantages in comparison with convoluted
> instruction set of X86 line.
"fauly" components? "bam" memory chips? "onle falty" CPU? "somce"?
"complier" level advantages??
That's serious advantage, we definitely don't have those.
I don't even know what those things are... ;)
--
vda
> http://www.softpanorama.org/Articles/Linux_vs_Solaris/sparc_vs_x86.shtml
>
>> ...
>> Linux is essentially an OS that flourishes only on Intel. It never achieved
>> any significant success on RISC architecture although IBM now is trying to
>> change this situation pushing Linux on PowerPC and potentially cannibalizing
>> its own AIX sales (at least on low level servers). Actually running several
>> competing with each other hardware and software offerings is nothing new for
>> IBM.
>
>> Solaris is heterogeneous OS that (unlike Linux) can perform well on two
>> architectures: UltraSparc and Intel. Actually Linux used to be more
>> heterogeneous in the past when it supported Alpha. But those days are long
>> gone.
>> ...
someone should send these guys a directory listing of linux/arch/
[snip]
>> * Fault tolerance. Sun servers can do amazing things with fauly components.
yeah! like toast bread :-)
-jb
>>Solaris is heterogeneous OS that (unlike Linux) can perform well on two
>>architectures: UltraSparc and Intel.
There are a lot of places where there seem to be artificial delays.
>>5.1. UltraSparc is an expensive but pretty cool CPU :-)
>>...
>>* Energy efficiency: it consumes less energy then either Intel or Opteron
>> and much less then PoewerPC CPUs.
Approx 82-85 W for an Opteron 244; according to Wikipedia, a T1 is 79 W.
UltraSPARC IV at 109 W (competes with P4 :p)
>>* Fault tolerance. Sun servers can do amazing things with fauly components.
>> almost any of them can be switched off. Even low level Sun server like V240
>> can survive bam memory chips, onle falty CPU and one burned power supply.
>> In some somce it is an cheap cluster.
I once pulled one power cable from a 2-PSU E250 machine. It powered off.
That can't be fault tolerant.
Plus you can't replace components (in an E250) without turning the power
off. That's because opening the case disconnects the power circle.
>>* Cleaner architecture. Being big Endean CPU with RISC instruction set
>> provides some complier level advantages in comparison with convoluted
>> instruction set of X86 line.
Except that the instruction length is a bit shortcoming for 64-bit integer
math. Under x64, you can do
movq $biglongconstant, %rax
while on SPARC, it takes 6 instructions (of course, being RISC makes it
execute differently than x64)
sethi %g1, $some_upper_bits
or %g1, $next_bitgroup
(shift-left)
or %g1, $next_bitgroup
(shift-left)
or %g1, $last_bitgroup
BTW, T1 is cool, but that the 1U version only has space for 1 disk is
pretty limiting :/
Jan Engelhardt
--
jimmy <[email protected]> writes:
>> http://www.softpanorama.org/Articles/Linux_vs_Solaris/sparc_vs_x86.shtml
>>
>>> ...
>>> Actually Linux used to be more heterogeneous in the past when it
>>> supported Alpha. But those days are long gone.
>>> ...
> someone should send these guys a directory listing of linux/arch/
I think he's confusing Red Hat with Linux. But these days even Red Hat
supports more architectures than Solaris: i386, amd64, ia64, ppc64 and
s390.
--
ilmari
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen
On 5/4/06, Dagfinn Ilmari Manns?ker <[email protected]> wrote:
> jimmy <[email protected]> writes:
>
> >> http://www.softpanorama.org/Articles/Linux_vs_Solaris/sparc_vs_x86.shtml
> >>
> >>> ...
> >>> Actually Linux used to be more heterogeneous in the past when it
> >>> supported Alpha. But those days are long gone.
> >>> ...
> > someone should send these guys a directory listing of linux/arch/
>
> I think he's confusing Red Hat with Linux. But these days even Red Hat
> supports more architectures than Solaris: i386, amd64, ia64, ppc64 and
> s390.
>
Don't pay too much attention:
"I have a subjective impression that networking in Linux is less
sophisticated..."
"As for LDAP quality I have no data but suspect that Solaris has an
upper hand..."
"Based on my limited knowledge of Linux kernel development it looks
like Linux development suffered from a classic case of premature
optimization disease..."
--
Dmitry
From: Jan Engelhardt <[email protected]>
Date: Thu, 4 May 2006 13:31:37 +0200 (MEST)
> while on SPARC, it takes 6 instructions (of course, being RISC makes it
> execute differently than x64)
>
> sethi %g1, $some_upper_bits
> or %g1, $next_bitgroup
> (shift-left)
> or %g1, $next_bitgroup
> (shift-left)
> or %g1, $last_bitgroup
>
> BTW, T1 is cool, but that the 1U version only has space for 1 disk is
> pretty limiting :/
This example instruction sequence is incredibly misleading.
First of all, the vast majority of constants can be loaded in 1 to 3
instruction sequences. I know this because I wrote the code that
emits 64-bit constant loading in the sparc backend of gcc and I've
watched how it tends to work when compiling real code.
Yes, the code density sucks on sparc compared to any x86 variant,
32-bit or 64-bit, but there is no need to exaggerate.
For symbolic references, it depends upon the code model and whether
you are generating PIC or not. If you use the 32-bit medlow code
model, non-PIC, which is the default for apps being compiled under
sparc64/Linux, it's two instructions to load a symbol address.
The sequence gets progressively larger as you move onto the medmid
and midany code models.
Jan Engelhardt wrote:
> while on SPARC, it takes 6 instructions (of course, being RISC makes it
> execute differently than x64)
>
> sethi %g1, $some_upper_bits
> or %g1, $next_bitgroup
> (shift-left)
> or %g1, $next_bitgroup
> (shift-left)
> or %g1, $last_bitgroup
>
> BTW, T1 is cool, but that the 1U version only has space for 1 disk is
> pretty limiting :/
I have to believe that you can load 64 bit constant data from memory and
don't have to do all this dancing with immediate loads. Therefore this
must be faster or they wouldn't do it this way. Or is this a point that
some unoptimized compiler could generate this code?
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
>> while on SPARC, it takes 6 instructions (of course, being RISC makes it
>> execute differently than x64)
>>
>> sethi %g1, $some_upper_bits
>> or %g1, $next_bitgroup
>> (shift-left)
>> or %g1, $next_bitgroup
>> (shift-left)
>> or %g1, $last_bitgroup
>>
>> BTW, T1 is cool, but that the 1U version only has space for 1 disk is
>> pretty limiting :/
>
> I have to believe that you can load 64 bit constant data from memory and
> don't have to do all this dancing with immediate loads. Therefore this
> must be faster or they wouldn't do it this way. Or is this a point that
> some unoptimized compiler could generate this code?
gcc 4.1.0 -m64. (Debian unstable)
I also tried
gcc version 4.0.0 20041019 (Red Hat 4.0.0-0.8sparc) <Aurora SPARC> -m64
generating (`objdump -DS test.o`)
0000000000000000 <main>:
#include <stdio.h>
int main(void) {
0: 9d e3 bf 40 save %sp, -192, %sp
return printf("%lld\n", 0x12345678abcdefULL);
4: 03 00 00 00 sethi %hi(0), %g1
8: 90 10 60 00 mov %g1, %o0 ! 0 <main>
c: 03 00 04 8d sethi %hi(0x123400), %g1
10: 82 10 60 56 or %g1, 0x56, %g1 ! 123456 <main+0x123456>
14: 85 28 70 20 sllx %g1, 0x20, %g2
18: 03 1e 2a f3 sethi %hi(0x78abcc00), %g1
1c: 82 10 61 ef or %g1, 0x1ef, %g1 ! 78abcdef <main+0x78abcdef>
20: 92 00 80 01 add %g2, %g1, %o1
24: 40 00 00 00 call 24 <main+0x24>
Jan Engelhardt
--