Thursday Oct 18, 2012

Mixing Java and native code

This was a bit of surprise to me. The slides are available from my presentation at JavaOne on mixed language development. What I wasn't expecting was that there would also be a video of the presentation.

Monday Apr 25, 2011

Using pragma opt

The Studio compiler has the ability to control the optimisation level that is applied to particular functions in an application. This can be useful if the functions are designed to work at a specific optimisation level, or if the application fails at a particular optimisation level, and you need to figure out where the problem lies.

The optimisation levels are controlled through pragma opt. The following steps need to be followed to use the pragma:

  • The directive needs to be inserted into the source file. The format of the directive is #pragma opt /level/ (/function/). This needs to be inserted into the code before the start of the function definition, but after the function header.
  • The code needs to be compiled with the flag -xmaxopt=level. This sets the maximum optimisation level for all functions in the file - including those tagged with #pragma opt.

We can see this in action using the following code snippet. This contains two identical functions, both return the square of a global variable. However, we are using #pragma opt to control the optimisation level of the function f().

int f();
int g();

#pragma opt 2 (f)

int d;

int f()
{
  return d\*d;
}

int g()
{
  return d\*d;
}

The code is compiled with the flag -xmaxopt=5, this specifies the maximum optimisation level that can be applied to any functions in the file.

$ cc -O -xmaxopt=5 -S opt.c

If we compare the disassembly for the functions f() and g(), we can see that g() is more optimal as it does not reload the global data.

                        f:
/\* 000000          0 \*/         sethi   %hi(d),%o5

!   10                !  return d\*d;

/\* 0x0004         10 \*/         ldsw    [%o5+%lo(d)],%o4 ! volatile    // First load of d
/\* 0x0008            \*/         ldsw    [%o5+%lo(d)],%o3 ! volatile    // Second load of d
/\* 0x000c            \*/         retl    ! Result =  %o0
/\* 0x0010            \*/         mulx    %o4,%o3,%o0

                        g:
/\* 000000         14 \*/         sethi   %hi(d),%o5
/\* 0x0004            \*/         ld      [%o5+%lo(d)],%o4               // Single load of d

!   15                !  return d\*d;

/\* 0x0008         15 \*/         sra     %o4,0,%o3
/\* 0x000c            \*/         retl    ! Result =  %o0
/\* 0x0010            \*/         mulx    %o3,%o3,%o0

Thursday Mar 05, 2009

Reporting bugs

I figured I'd just write up some quick notes about how to report bugs, if you find them, against Sun Studio. There are various mechanisms.

  • First off, there are formal support channels. These are really for the situations where you need a timely response, or are using an older version.
  • The next place that can be useful are the Sun Studio forums. We do read these, and reply - they are very active. It can be useful to discuss problems here in case anyone has hit the same issue, or if you are uncertain whether the code or the compiler is at fault.
  • There is also a formal bug/rfe reporting service. If the compiler dies with an error, this is a good place to file that. Before reporting a new bug or rfe you should first take a look to see if someone else has already reported it. There's also support for watching the status of bugs, or voting for your top three (although the idea of a favourite bug is a bit disturbing).

In terms of what is useful to include:

  • Platform (chip, system type etc)
  • OS version
  • Compiler version
  • Compiler flags/commandline
  • symptoms etc
  • Call stack [dbx - core; whereami]

If the problem causes the compiler to crash with an error, then to reproduce the problem we'll need the source file. Obviously this depends on your environment and header files etc. To produce a preprocessed source file remove any -o <file.o> from the command line and add -P. -P will produce a preprocessed file <file.i>. Check that compiling <file.i> produces the same error, and submit that with the bug report. Obviously, don't submit files that you don't want anyone else to see!

Well, I hope that you never need this info!

Wednesday May 28, 2008

Updated article on compiler options

An updated version of my article on compiler options has been put up. I think I last refreshed this a couple of years back. It's interesting to see what difference a couple of years makes. I'd started the update with the expectation that things would have become much simpler, although this is true, there's still some complexity left. The major changes were:

  • More focus on -xtarget=generic. Really that's the best option to start with and to use when possible. But there are exceptions....
    • For x86 it's a good plan to use -xarch=sse2 -xvector=simd to get the compiler to use the SSE2 instruction set which is common on all recent x86 processors.
    • For SPARC the SPARC64 VI processor supports floating point multiply accumulate instructions. These are a boost for floating point codes, and are generated under the flags -xarch=sparcfmaf -xfma=fused
  • The compiler is pretty good at generating prefetch instructions by default, so there's no real need to emphasise the prefetch flags.
  • Profile feedback and crossfile optimisation are pretty common options, and should be considered for all applications.

Wednesday Nov 28, 2007

CMT Developer Tools webcast

I've just had another webcast posted. This time it's discussing the CMT Developer Tools. The tools are add-ons for both Sun Studio 11 and Sun Studio 12. Of particular excitement was getting two of the tools ported to x64. There's a bit more information on the individual tools on my post back in July when we released them.

The CMT Developer Tools webcast covers installing and using the tools. The presentation is part slideware and part demo.

Thursday Sep 13, 2007

Dwarf debug format

Just been looking at the dwarf debug format. In Sun Studio 12, all the compilers switched to using this format over the older stabs format. Chris Quenelle has put a useful guide to debug information up on the Sun Wiki. The dwarf format overview document is probably the easiest to read, the version 3 specification document is more detailed. The tool to extract the dwarf information from an object file is dwarfdump. For example the -l flag will extract line number info.

Wednesday Apr 11, 2007

Solaris observability tools

A comprehensive list of the observability tools shipped with Solaris. Unfortunately the links on the page go to the source of the tool rather than the man page.

About

Darryl Gove is a senior engineer in the Solaris Studio team, working on optimising applications and benchmarks for current and future processors. He is also the author of the books:
Multicore Application Programming
Solaris Application Programming
The Developer's Edge

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
5
6
8
9
10
12
13
14
15
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
The Developer's Edge
Solaris Application Programming
Publications
Webcasts
Presentations
OpenSPARC Book
Multicore Application Programming
Docs