This release include a small number of bug fixes, some new object library, support for the new Sgi audio library and dynamic loading.
Starting from this release, FTS will only run on standard platforms including a complete ANSI-C compiler and a complete libc library, including access to the file system and to standard system resources; the only kind of parallelism supported will be based on SMP architectures.
In more specific terms, it means that this release, and all the future releases, will not run on the ISPW platform.
Also, it means that object programmer are free to access the whole set of libc and filesystem functionalities.
Also, a small number of incompatible change in the API has been done to suppress some old ISPW dependent weirdness ; see the paragraph below.
The 6.3/6.4 version support the new audio library, and so the ADAT I/O available on some of the machines; for this release, FTS will always use only the default audio device for input and output, so the number of channels is limited to 8 in and 8 out (you have to set the default audio device with the audiopanel application); future releases will support multi-device I/O.
All the different binaries and libraries for SGI are included in a single distribution; take care during the installation process to be sure that the ftsArch resource is set to the good value, otherwise you will run the wrong binary (getting an unexpected lower performance); see the INSTALL file for further details.
Dynamic loading is organized around the concept of module, in the same way the static linking is organized; the programming convention introduced for static linking must be kept for dynamically loadable modules.
A module is a collection of classes; a module is stored as a library; for dynamic linking, a module must be pre-linked to a DSO (dynamic shared object) format, using the ld command (the scripts and Makefiles has been updated to do so).
In order to use the classes in the module, a declaration for the class
must be created (or loaded); a class declaration is an object named
"class", with three arguments: the class name, the module name and an
optional file name (that default to lib
For example, the object "class frob frob-utils" declare a class named
"frob", that is implemented in the module frob-utils, stored on disk
as a .so file named libfrob-utils.so.
The module is loaded the first time a frob object is created; if you
try to create a frob object before creating its declaration, FTS will
signal a "object not found" error.
The file argument can be an absolute path name; otherwise, it can be a
file name or a relative path; in this case, the .so file is searched
in all the directory included in the patchPath resource.
The correct way to deliver a library in this format is to pair the
shared library with a .pat file that include all the declarations for
this library; so that by loading the declaration patch, all the
classes become accessible.
This implementation is limited because, since Max do not guarantee, at
the moment, that the order of object creation is respected, it is not
possible to guarantee that a declaration is loaded before the objects
that need it; in other words, you cannot include a declaration patch
in an application, you need to load the declaration patches by hand
before loading the application patches; this will be fixed in future
releases.
This implementation is experimental, in the sense that declaration
formats may change in future releases.
Also, consider that for the moment we don't guarantee binary
compatibility between releases, and FTS support more than one binary
platform, both on the SGI and on other (coming soon) platforms; so,
mark clearly the version and binary platform when distributing shared
libraries for FTS.
The script make-fts-lib has been fixed, and extended to support
dynamic loading (the .so file is automatically generated).
The sys_log function do not exist anymore; since FTS is now a fully
The FTS profiling system has been removed; on modern platforms the
system provide utilities far better than anything we could build for
profiling or analysing the FTS performance; see the next paragraph of
this release notes about which tools you can use for profiling your
objects.
The
Also, since now the object can include the full supported range of
formatting code (the ISPW platform didn't allowed this), the special
type specific post function (poststring, postlong, postxlong,
postfloat and their cpost counterpart) have been deleted.
Perfomance data can be easily obtained with the two utilities
gr_osview (or gr_top) and rbview (also callable from the audio panel);
the first give you information about machine load (and gr_top divide
this load between processors, so you can know if it is really FTS to
load the machine); the second give you information about the audio
fifo length, and on the number of underrun error FTS got; an underrun
error means that FTS was too slow to produce enough samples (or the
rest of the system got too much CPU time), and is the equivalent of
the old ISPW "dac slip" message.
In order to have a better analysis of the performance of the code,
you can use the speedshop suite of analysis tool; speedshop can give you
detailed data down to the single line of code, using pixie based or
pc-sampling techniques, and/or other data like the number of floating
point exception, the primary and secondary cache behaviour and others.
Refer to the correct manual pages; in order to run Max and fts with speedshop,
the simplest thing to do is to write a script like this:
Finally, if what you want to know is just the absolute performance of
a complete application in sample per seconds, you can, as usual, use
the profile-dac devices to get it.
Development scripts
The make-fts script and the relative FTS libraries are not distributed
anymore starting from this release; they are still available for special
purpose on case by case base; dynamic loading is the recomended way to
use user object libraries. Incompatible Changes in the Kernel FTS APIs
The fts_malloc and fts_zalloc functions drop
the second argument; the second argument was used to require a specific
kind of memory on architectures with user visible un-uniform memory
architecture, like the C40 or the ISPW, architectures that will
be never supported again; so better suppress the argument now than
keeping it for the future centuries without a reason. libc environment, you can use a fprintf call
on the standard error to get diagnostic printouts.post function was changed to have the same behaviour
than the standard printf; the syntax of the formatting
string is the same, and the post function do not add
anymore newlines at the end of each printout; this give the object
programmer more control on the output; the newline explicitly inserted
by the programmer behave as expected in the post window; the same
change hold for the welcome messages. Profiling FTS in an SGI machine
There are two kind of profile data you can be interested in;
perfomance data, i.e. low overhead, non intrusive data on the actual
machine load during a performance, and analysis data, i.e. a deeper
analysis on how FTS spend its time.
#!/bin/sh
exec ssrun
Call it something like "fts.ss", and run Max with the "-n fts.ss"
option.