Any good ways to allocate nearly 4GB in SPARC asm prog ?

Any good ways to allocate nearly 4GB in SPARC asm prog ?

Post by Andrei A. Dergatch » Sat, 16 Oct 1999 04:00:00



Hi,

I'm moving my program from C to asm to achieve
a better performance, and I'd like to use this chance
to drop C-sh malloc as I read enough about its own
problems (with multitheads, being slow etc).

My platform is UltraSPARCs running Solaris 7.

Various manuals and books tell me that something
as simple as
array: .skip 3200000000
should work for allocation of double array[400000000],
except that nowhere I can find a clarification of if I
have to care about 32-bitness in the argument for skip.
Another option I know of is stack, however I guess
there's no OS around which will like that :-)

Any there any other approaches, probably better, to
do it ?

Thanks a lot for any help,

Andrei

 
 
 

Any good ways to allocate nearly 4GB in SPARC asm prog ?

Post by Andrew Giert » Mon, 18 Oct 1999 04:00:00


 Andrei> I'm rather surprised to see a lot of references to misaligned
 Andrei> data like "std %f4,[%sp+2375]" even when compiled with
 Andrei> "-dalign".

Whether this is misaligned depends on the value of %sp - I believe that
in 64-bit Sparc code the stack pointer is offset by some factor, 2047
I think. 2375-2047 is aligned to 8 bytes.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

 
 
 

Any good ways to allocate nearly 4GB in SPARC asm prog ?

Post by Keith Thompso » Wed, 20 Oct 1999 04:00:00



[...]

Quote:> I'm way too busy to waste my time for no reason. Some kind
> soul compiled my program with Digital C and ran it on the Alpha
> 21264. A difference in execution speed comparing to my combo -
> Sun C on UltraSPARC - is more then order of magnitude. Yet I
> spent already quite some time tinkering with various compilation
> options for the SC. As my program in present state isn't that
> complicated and I can't wait days when I know I can get results
> in hours I see the assemler as the only way to go :-(

At the risk of stating the obvious, have you tried profiling your
code to determine where the bottlenecks are?  I vaguely recall
something about very large mallocs taking a disproportionately long
time; I *think* it was on Solaris.  (Try doing a deja.com search in
comp.unix.solaris, or possibly comp.lang.c{,.moderated}.)  If something
like that explains the bulk of the speed difference, optimizing that
one section of code (perhaps by coding it in assembler, perhaps by
choosing a better algorithm) will be a lot easier than rewriting
the whole application.  It will also make it a lot easier to port
to other systems, especially if you keep the C implementation as a
portable alternative.

Translating from C to assembler *will* be a waste of time unless you
have good reason to believe you can write better assembler than the
compiler can.  It's not as smart as you are, but it's far more patient.

If you've already tried and rejected this, or if this is what you
were talking about in the first place (I missed the original article),
then never mind.

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
"Oh my gosh!  You are SO ahead of your time!" -- anon.

 
 
 

Any good ways to allocate nearly 4GB in SPARC asm prog ?

Post by Andrei A. Dergatch » Thu, 21 Oct 1999 04:00:00


Hi,

Thanks for your response,


Quote:>At the risk of stating the obvious, have you tried profiling your
>code to determine where the bottlenecks are?

Yes.

Quote:> I vaguely recall
>something about very large mallocs taking a disproportionately long
>time; I *think* it was on Solaris.  (Try doing a deja.com search in
>comp.unix.solaris, or possibly comp.lang.c{,.moderated}.)  If something
>like that explains the bulk of the speed difference, optimizing that
>one section of code (perhaps by coding it in assembler, perhaps by
>choosing a better algorithm) will be a lot easier than rewriting
>the whole application.

I looked into that already. It seems to be not the case.

Quote:>  It will also make it a lot easier to port
>to other systems, especially if you keep the C implementation as a
>portable alternative.

This project aims to get highest speed out of the only
platform available, so portability is not the issue for
me in this case.

Quote:

>Translating from C to assembler *will* be a waste of time unless you
>have good reason to believe you can write better assembler than the
>compiler can.  It's not as smart as you are, but it's far more patient.

Yes, in general case I agree with you. The only reason why
I stated boldly "rewrite in asm everything" is that in fact
this program is rather short and primitive.

Quote:

>If you've already tried and rejected this, or if this is what you
>were talking about in the first place (I missed the original article),
>then never mind.

Well, in fact I mainly was concerned with seemingly
unaligned pattern of dealinbg with the %sp but as
it turned out everything is ok.

Still no one answered my original question though :-(
Is everyone using malloc and no one ever allocated
a big chunk of memory in pure asm under SunOS ?

>--

>San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
>"Oh my gosh!  You are SO ahead of your time!" -- anon.

Thanks again to everyone who replied,
Rgds,

Andrei

 
 
 

Any good ways to allocate nearly 4GB in SPARC asm prog ?

Post by Spike Whit » Thu, 21 Oct 1999 04:00:00



Quote:>>> I'm moving my program from C to asm to achieve
>>> a better performance, and I'd like to use this chance

>>With all dur respect, in these days of highly optimising
>>compilers, I'd be very surprised if you could get any
>>worthwhile performance benefits over using C.

>I'm way too busy to waste my time for no reason. Some kind
>soul compiled my program with Digital C and ran it on the Alpha
>21264. A difference in execution speed comparing to my combo -
>Sun C on UltraSPARC - is more then order of magnitude.

Which model UltraSPARC.  You may have an old model,
re-writing in assembly won't help slow CPUs.
 
 
 

Any good ways to allocate nearly 4GB in SPARC asm prog ?

Post by Casper H.S. Dik - Network Security Engine » Thu, 21 Oct 1999 04:00:00


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


Quote:>Yes, in general case I agree with you. The only reason why
>I stated boldly "rewrite in asm everything" is that in fact
>this program is rather short and primitive.

So, post it.  Only then can we give any useful sugestions.

Quote:>Still no one answered my original question though :-(
>Is everyone using malloc and no one ever allocated
>a big chunk of memory in pure asm under SunOS ?

If malloc is a problem, why not use "static" in C?

(That's all asm will allow you to do or you're need to start calling
brk (which you can do in C) or malloc.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Any good ways to allocate nearly 4GB in SPARC asm prog ?

Post by Andrei A. Dergatch » Fri, 22 Oct 1999 04:00:00




>[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>>Yes, in general case I agree with you. The only reason why
>>I stated boldly "rewrite in asm everything" is that in fact
>>this program is rather short and primitive.

>So, post it.  Only then can we give any useful sugestions.

It was already posted in comp.unix.solaris group.
In deja archives it is around here:
http://x47.deja.com/getdoc.xp?AN=528784863.4&search=thread&CONTEXT=94...

Quote:

>>Still no one answered my original question though :-(
>>Is everyone using malloc and no one ever allocated
>>a big chunk of memory in pure asm under SunOS ?

>If malloc is a problem, why not use "static" in C?

No, malloc is not really a problem, I was just curious :-)

Quote:

>(That's all asm will allow you to do or you're need to start calling
>brk (which you can do in C) or malloc.

>Casper
>--
>Expressed in this posting are my opinions.  They are in no way related
>to opinions held by my employer, Sun Microsystems.
>Statements on Sun products included here are not gospel and may
>be fiction rather than truth.

Andrei