Solaris

Hello helpful Unix gurus!

First, I appreciate any help I can get.

I have a product that we have ported (for years now) on Solaris SPARC 7.x OS from 1998 (or around that time I guess) that is compiled to a 32 executable. It has run (with various modifications over the years) on any Solaris SPARC platform (as far as I know).

Recently I have a customer that expects the program to run much faster. This program is a number crunching type of utility that goes off and does file input, parsing, bit manipulation and output and then exits, so normally it is pretty fast). It is written in C/C++ and is compiled to mostly native code with a few calls to the C run time library (static linkage).

So my question is this: is the fact that this is a 32 bit SPARC executable slowing down its running on a 64 bit SPARC. It is running on the following Solaris platform:

Code:

uname -a
SunOS appomahadev2 5.10 Generic_147440-01 sun4v sparc sun4v Solaris

isainfo -v
64-bit sparcv9 applications
        hpc vis3 fmaf asi_blk_init vis2 vis popc
32-bit sparc applications
        hpc vis3 fmaf asi_blk_init vis2 vis popc v8plus div32 mul32

I am asking to see:

1. if there is a known reason why the 32bit exe should run slower on a 64 bit platform?

2. if re-compiling this code on a newer Solaris SPARC 64 OS
will generate a SIGNIFICANTLY faster executable?

Getting a new Solaris SPARC box seems to be expensive and is not something we really want to do unless we need to.

Does anyone know of a cross compiling method whereby we can compile on a cheaper platform and target this platform?
Any ideas?

So you are running on a niagara type cpu (T1, T2, ...). These are cpus with a lot of cores and threads but with limited single thread power. When you say, it is an old application, then it is most likely a single threaded one and not very well suited for such an architecture (or vice versa).

Recompiling in 64 bit mode could speed up things a little, if there is a lot of 64 bit arithmetic going on in the program. But I would not expect to much from this step.

Alternatively, you might redesign your application code for it to be multi-threaded. It might run 8 times faster than its current speed on sun4v.

Thank you both for your insight.

The program is a single threaded type of process. It has to be that way.
However, we will try arranging to run the executable in parallel if possible.

If I understand you correctly then running say 10 of these processes at the same time instead of in sequence "should" process much faster (rather than just a little faster on a normal single core machine). Is that correct?

That really depends on your process characteristics. If your process is heavily doing floating point arithmetics, there would be a notable gain with a T2 (but not that much on a T1). If your process is I/O or memory bound, there should be no significant gain. If the process is CPU bound, you can expect it to run at least 8 times faster. If your process I/Os are introducing latencies that can be parallelized, you can expect it to run up to 64 times faster.

I'm assuming an 8 core, 8 thread per core CPU.

Again, thank you for your responses.

So please let me clarify a few points to be sure.

1. 'hergp' is saying that if the issue is that they are using a T1 T2 type multi core SPARC than the issue is not so much the 32 vs 64 bit compile as it is the single threaded vs multi-threaded processing. Correct?
On Windows x86 vs X64 we found that the increase in compiling to X64 is just under 20% (comparing the running of one process on the same input data). Would you expect something similar on SPARC?

2. 'jlliagreis' saying that if it is possible to design our program to be multi-threaded (which I don't think we can) or if we run the program in parallel processes on different sets of data instead of in sequence, then we should be able to see some improvement. However, the amount will depend on the type of bottle neck we are experiencing (which we do not know yet). So for example, if it is straight CPU bound then we should see the best improvement, whereas if it is I/O bound then they may be less improvement, etc.

3. How do I know if we are running T1 or T2 with regard to floating point? I noticed that you said it is niagara based on the sun4v. How do I tell what T level they have?

4. What Solaris SPARC hardware would be better for doing this type of processing? I am not sure we have a choice but I am certainly curious.

---------- Post updated at 04:40 PM ---------- Previous update was at 09:38 AM ----------

One other things. They have two servers. One is a T2 and the other a T3 and specifically they are:SunOS 5.10 Generic_147440-09 sun4u sparc SUNW,Sun-Fire-V245 (T2)
SunOS 5.10 Generic_147440-01 sun4v sparc sun4v (T3)

What does this tell us about single thread / multi-thread or floating point etc?
How does sun4v differ from sun4u? How does T2 differ from T3?

Thank you.

Just to inject another point of vie. hergp and jllaigre are correct about threading.

To answer your 32/64bit question: time it yourself on the same dataset with two different compiles. We have done that on a different solaris architecture and found only a small amount of improvement.

If your number cruncher uses big arrays it is possible that you are wasting cpu. If your code constantly forces the cpu to bring in pages of data and to do a lot of searching in the cached pages, you are possibly wasting cpu.

Consider running your code and at the same time run trapstat. Thanks to this we got data to support using larger pagesize effectively. This DOES NOT nesessarily involve coding. A minor change to the way you invoke your code is needed. See the ppgsz man page for a very simple way to do this. Do this if and only if you have an MMU issue issue revealed by trapstat. And I do not know much about your architecture, this may not be as beneficial as it was on our M4000.

Have a read:
Multiple Page Size Support - Siwiki