[9fans] sparc port, number crunching

[9fans] sparc port, number crunching

[John Stalker]

I am thinking of buying a 12-cpu ultrsparcII unit (E4500) for a
couple of scientific computing projects I am working on.  My OS
choices seem to be
1) Solaris 8, 9, or 10
2) NetBSD
3) Plan9
Option (1) is obviously the safe, conservative option.  Option (3)
would be the most fun.  Anyone have any relevant experience?  From
``the Various Ports'' it seems that I may need to fix up floating
point support in the compiler.  Am I likely to run into other
problems?  I can only expect to get away with option (3) if the
performance is roughly comparable--say, to within a factor of
two--with option (1) and if the amount of systems programming
needed is zero or small.  The main external library which would
need porting is libfftw for the Fast Fourier Transform.
--
John Stalker
University of Dublin, Trinity College
School of Mathematics

Re: [9fans] sparc port, number crunching

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

What I would add is that if you need to do anything on the local terminal,
option two is almost certainly out of the question. I have several xBSD
ultrasparc II{e,i} boxes here and the local video is terrible. Over the
network is fine (although with some machines the happy meal ethernet isn't
the best (SPARCengines...)), but local always sucks.

On 10/10/05, John Stalker <stalker@maths.tcd.ie> wrote:
>
> I am thinking of buying a 12-cpu ultrsparcII unit (E4500) for a
> couple of scientific computing projects I am working on. My OS
> choices seem to be
> 1) Solaris 8, 9, or 10
> 2) NetBSD
> 3) Plan9
> Option (1) is obviously the safe, conservative option. Option (3)
> would be the most fun. Anyone have any relevant experience? From
> ``the Various Ports'' it seems that I may need to fix up floating
> point support in the compiler. Am I likely to run into other
> problems? I can only expect to get away with option (3) if the
> performance is roughly comparable--say, to within a factor of
> two--with option (1) and if the amount of systems programming
> needed is zero or small. The main external library which would
> need porting is libfftw for the Fast Fourier Transform.
> --
> John Stalker
> University of Dublin, Trinity College
> School of Mathematics
>



--
The subject of this essay (the Myth of Sisyphus) is precisely
this relationship between the absurd and suicide, the exact
degree to which suicide is a solution to the absurd. The
principle can be established that for a man who does not cheat,
what he believes to be true must determine his action.
Belief in the absurdity of existence must then dictate his
conduct. It is legitimate to wonder, clearly and without
false pathos, whether a conclusion of this importance
requires forsaking as rapidly possiblean imcompre-
hensible condition. I am speaking, of course, of men
inclined to be in harmony with themselves.
<< Albert Camus>>

[-- Attachment #2: Type: text/html, Size: 2379 bytes --]

Re: [9fans] sparc port, number crunching

[Russ Cox]

> I am thinking of buying a 12-cpu ultrsparcII unit (E4500) for a
> couple of scientific computing projects I am working on.  My OS
> choices seem to be
> 1) Solaris 8, 9, or 10
> 2) NetBSD
> 3) Plan9

There was a Sparc kernel once, and some people (Chris Collins?)
have been reviving it, but I don't know that I'd want to depend on
it being ready in time to use for your app.  Perhaps Chris will
speak up.

Russ

Re: [9fans] sparc port, number crunching

[John Stalker]

This sounds worse than I expected.  How much has the platform-dependent
part of the kernel changed since we last had a fully functional sparc
kernel?

On a related note, the plan9 sparc compiler was claimed to produce
code comparable in speed to GCC.  Does anyone know how it compares
to Sun's compiler?

> There was a Sparc kernel once, and some people (Chris Collins?)
> have been reviving it, but I don't know that I'd want to depend on
> it being ready in time to use for your app.  Perhaps Chris will
> speak up.
> 
> Russ

--
John Stalker
University of Dublin, Trinity College
School of Mathematics

Re: [9fans] sparc port, number crunching

[Ronald G Minnich]

John Stalker wrote:

> On a related note, the plan9 sparc compiler was claimed to produce
> code comparable in speed to GCC.  Does anyone know how it compares
> to Sun's compiler?


well, there's a blast from the past:

"gcc code output quality used as 'good' in compiler comparison" :-)

ron

Re: [9fans] sparc port, number crunching

[John Stalker]

The original words were

  The SPARC compiler is also solid and fast, although we haven't used
  it for a few years, due to a lack of current hardware. We have seen
  it do much better than GCC with all the optimizations, but on average
  it is probably about the same.

I suspect the comparison is with GCC rather than Sun Studio 8/9/10
because GCC is free (as in beer) rather than because it is the holy
grail of compiler development.

> John Stalker wrote:
> 
> > On a related note, the plan9 sparc compiler was claimed to produce
> > code comparable in speed to GCC.  Does anyone know how it compares
> > to Sun's compiler?
> 
> 
> well, there's a blast from the past:
> 
> "gcc code output quality used as 'good' in compiler comparison" :-)
> 
> ron

--
John Stalker
University of Dublin, Trinity College
School of Mathematics

Re: [9fans] sparc port, number crunching

[Charles Forsyth]

> I suspect the comparison is with GCC rather than Sun Studio 8/9/10
> because GCC is free (as in beer) rather than because it is the holy
> grail of compiler development.

it is difficult to compare kc directly in any case, because it uses
the registers differently (it ignores register windows).  that might be bad
if they saved you a few stores, but might be good if you use processes or coroutines.

more important, gcc is the holy cow of compilers, not the holy grail.

Re: [9fans] sparc port, number crunching

[Lyndon Nerenberg]

On Oct 11, 2005, at 4:45 PM, Charles Forsyth wrote:

> more important, gcc is the holy cow of compilers, not the holy grail.

Another entry for the fortune file.

Re: [9fans] sparc port, number crunching

[erik quanstrom]

a couple of weeks ago, i got a wild hair and compiled the stuff i'm working
on with tcc and icc. both produced debugging executables that were
at least a third smaller and tcc runs in 10% or less of the time of gcc.

	size		time 'make all'
gcc	579785		1.55user 0.94system 0:02.59elapsed
tcc	358460		0.18user 0.06system 0:00.30elapsed
icc	398670		1.10user 0.80system 0:02.04elapsed


Lyndon Nerenberg <lyndon@orthanc.ca> writes

| 
| 
| On Oct 11, 2005, at 4:45 PM, Charles Forsyth wrote:
| 
| > more important, gcc is the holy cow of compilers, not the holy grail.
| 
| Another entry for the fortune file.

Re: [9fans] sparc port, number crunching

[Christopher Nielsen]

On Mon, Oct 10, 2005 at 03:50:15PM -0400, Russ Cox wrote:
> > I am thinking of buying a 12-cpu ultrsparcII unit (E4500) for a
> > couple of scientific computing projects I am working on.  My OS
> > choices seem to be
> > 1) Solaris 8, 9, or 10
> > 2) NetBSD
> > 3) Plan9
> 
> There was a Sparc kernel once, and some people (Chris Collins?)
> have been reviving it, but I don't know that I'd want to depend on
> it being ready in time to use for your app.  Perhaps Chris will
> speak up.

There was also a sparc64 kernel that Tim Newsham had ported.
I don't know the status or if anyone is maintaining it, but I
do know from my conversations with Tim that it doesn't support
SMP. There was a chance that I was going to acquire an E420R
and work on SMP support, but that didn't work out.

Chris

-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin