64ábits seems to be a
buzzword of current mobile computing, but it is quite common in
the PC space. Despite we use 64ábit
systems for a couple of years, general understanding what this
exactly means is low. Let us explain a few terms before we
describe 64ábit version of SIPS.
64ábit CPU is a computer
processor with internal registers, holding and processing
individual pieces of information (integer numbers, memory
pointers, ...), up to 64ábits long.
The first microprocessor ever was 4ábit (Intel 4004), but it was soon replaced by
8ábit version (Intel 8008).
8ábit CPUs become widely popular and
numerous models appeared (Intel 8080, Zilog Z80, Motorola 6800,
MOS Technology 6502, ...) and they powered first truly personal
computers. In a chase for greater computing power and the ability
to access more memory 16ábit and
later 32ábit processors appeared,
some of them created as extension of existing architectures, some
designed from the scratch to be directly 16áor even 32ábit.
Continuous demand for more memory caused the 4áGB limit, allowed by 32ábit processors (2^32á=á4G) was exceeded
and a room for 64ábit processors
opened. And similarly, some of them were natural extension of
older 32ábit architectures, some of
them were newly designed as 64ábit.
But processor architectures have tough life. They either become
successful and widely spread or die soon. Currently only two
architectures dominates (Intel x86-64 and ARM v7/v8) and both are
available in 64ábit variant. And both
evolved from previous 32ábit
versions, so they are able to run both 32ábit and 64ábit
64ábit operating system
needs 64ábit CPU to run. While a
purely 64ábit OS, requiring
64ábit applications only, could be
designed, it is almost impossible to succeed on the market. People
need to run existing applications, so a backward compatibility is
a key to success.
To achieve compatibility, both hardware (CPU) and
software (operating system) must support it. And all major
players do this (x64 and ARM, Windows and Android).
64ábit CPU can run both
32ábit and 64ábit operating system and applications. If
32ábit OS is run, the whole system
acts as purely 32ábit, including
memory address space limitations. It is not possible to use any
64ábit piece of code, 64ábit applications do not work.
When 64ábit CPU runs
64ábit OS, it is possible to run
both 32ábit and 64ábit applications.
So 64ábit Windows can run both 32ábit and 64ábit
SIPS without any problems.
But there is one important limitation. It not possible to
mix 32ábit and 64ábit code in one process. One process is
either completely 32ábit or
completely 64ábit, including all
DLLs, drivers and other components. The same is true for the
operating system kernelŚif it is
64ábit version, all device drivers
must be 64ábit,
Similarly drivers for user applications
must be 32ábit if the application
is 32ábit (rememberŚmajority of applications are still 32ábit), despite the application runs on
64ábit CPU and OS.
The fact that 32ábit and
64ábit code cannot be mixed and
64ábit code is always newly
translated/modified allowed CPU designers to more or less modify
the instruction set. Both AMD with x86-64 and ARM with v8 took
advantage of introduction of a new 64ábit mode and upgraded the respective
architectures. x64 somewhat reorganized register set, making it
more regular, and doubled number of registers (from 8 to 16). ARM
similarly removed conditional execution of all instructions and
used the saved space in the instruction word to address twice as
much registers (32 instead of 16). So it is not exaggeration to
say that 64ábit ARM v8 is a
completely new architecture, only similar to 32ábit ARM v7 (similarly like 16ábit Intel 8086 remotely resembled 8ábit Intel 8080).
64ábit version of SIPS is
essentially the same as 32ábit
version. It is naturally able to use much more memory, which comes
handy especially when SIPS uses image sets with hundreds of images
and the PC is equipped with more than 4áGB of memory. And it of course needs
64ábit versions of all device
drivers, but all supported drivers comes with the program itself
so this is not a problem.
As was noted in the previous chapter, 64ábit applications keep pointers (addresses of
data in memory) in twice as long registers compared to
32ábit programs. So naturally
64ábit programs are somewhat longer
and they need to operate larger amount of data even if they do
not use memory above 4áGB. This is
kind of performance penaltyŚlonger code
means larger memory traffics and effectively shrinks sizes of
fast cache memory. But on the other side, 64ábit code can use twice as much registers to
keep various variables (in the case of x64) and it does not need
to access memory so often, which causes performance gain. So the
question isŚis the 64ábit code faster or slower compared to
32ábit code? In reality it can be
both faster and slower, depending on the algorithm:
When the algorithm is very simple and mainly moves data
in memory, the 32ábit code is
typically faster. x86 CPU has enough registers for simple
algorithms and operating just 32ábit pointers naturally needs less resources
compared to 64ábit
Typical example is Median filter, which goes
through large number of pixels, but the most complex operation
performed is simple comparison of pixel values. 32ábit version of SIPS is somewhat faster than
64ábit version in this
Median filter test on 16ábit and 32ábit FITS files shows slowdown of
64ábit code (x64) compared to
More complex algorithms, which can utilize all 16
registers available in 64ábit mode
of x64 CPUs on the other side run significantly faster compared
to 32ábit version.
complex algorithm is for instance searching for stars within an
image. Numerous tests are performed to determine whether each
particular pixel is a part of star image or if it is solitary
hotpixel etc. Also numerous floating point operations are
performed (calculation of standard deviation of aperture area
etc.). 64ábit code is significantly
faster here compared to 32ábit code
and even a medium-class Core i5 CPU running 64ábit code can outperform top-of-the-class Core
i7 running 32ábit
Star search algorithm running on single core (left)
and multi core (right), 64ábit
version (x64) is considerably faster
Naturally integer calculations using whole 64ábit integers are much faster on x64 CPU. While
x86 CPU can of course perform such calculations, several
instructions are necessary to handle single 64ábit calculation in 32ábit mode, while 64ábit CPU needs only single instruction.
Unfortunately SIPS has no use for such large integers, so
potential speed gain is not utilized here.
Hi-DPI display support
While support for high DPI (high resolution) displays were
added to previous SIPS versions, some tools (Histogram and
Stretch, Cooling tab in the Camera tool, ...)
remained fixed to 96 DPI displays. But high resolution displays
provide much smoother image and they are more and more common even
in the case of cheap 2áiná1 and convertible computers.
Beside flexible adjustment of Cooling tab to Hi-DPI
displays, the temperature range was increased up to -75C, because new EC (Enhanced Cooling) models of Gx
cameras provide temperature drop up to 60C below ambient and -50C minimum temperature was no low enough.
New SIPS finally brought all features to the Telescope
(mount) drivers and control tools. Beside basic functions
(coordinates, goto, ...), it is now possible to
Park and Unpark the mount, as well as SetPark
Read and update mount location information (possibly
obtained from a GPS receiver attached to PC).
Read and set mount tracking (on/off) and choose tracking
speed (sideral, solar, lunar).
Synchronize mount time with PC time (again possibly
obtained from a GPS receiver attached to PC or synchronized over
the Internet with Time Servers).
Evolution of the Telescope tool from SIPS
v2.0 (left) to SIPS v2.3.3 (right)
The New FITS Header tool allowed manual,
semi-automatic or fully automatic entry of some
Manual entry headers are for instance OBJECT or TELESCOP.
User simply have to check the header and fill the particular
edit box. Then the header appears in FITS file.
Semi-automatic headers are for instance observatory
location (LONG-OBS, LAT--OBS and ELEV-OBS). It is possible to
fill these headers manually or click the Get Location from
GPS button to read them from GPS receiver.
Fully automatic headers do not allow any intervention
from the user, e.g. EXPTIME, FILTER or IMAGETYP. Values of these
headers are assigned by software upon image
New version of SIPS introduced updated New FITS
Header tool, which clearly distinguishes between automatic
and manual filling of respective headers. Such headers allow user
to define their value in the edit box, but also allow to check the
option to update the value upon image acquisition, providing the
proper information is available.
Let's take newly introduced RA and DEC headers as example. They
should contain equatorial coordinates of the image center. It is
possible to enter their value manually, but if the telescope
driver is active and provides telescope coordinates, it is
possible to check the option R.A./Dec. from telescope
to fill these headers each time the new image is downloaded from
the camera automatically.
The New FITS Header tool allows optional
automatic filling of selected header values
Camera tool now supports guiding not only through guider camera
with AutoGuider port, but also through a telescope
driver, providing the driver supports PulseGuide
SIPS now properly handles FITS blank comment lines.
Lines beginning with no keyword at all (only spaces) have to be
considered as comment lines and SIPS was updated to work properly
with FITS files using this feature.
SIPS is a freeware and can be downloaded from the Download section of this web site.