64 bit computing

“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 code.

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.

  Remark:

  Here is a source of confusion among many users. They have 64 bit CPU and 64 bit version of Windows, so they think all they run is 64 bit. In fact, only a very few applications are 64 bit, absolute majority are still (2014/2015) in 32 bit form only. And because they never need more than 4 GB of memory and work seamlessly, there is no pressure to rebuild them to 64 bit version.

  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, too.

  Remark:

  This is why Gx camera system drivers are available as 32 bit and 64 bit versions for quite a long time. It is necessary to use 64 bit version of the system driver if 64 bit OS is used, despite the user application controlling the camera is 32 bit only.

  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 SIPS

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 pointers.

  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 case.

  

  Median filter test on 16 bit and 32 bit FITS files shows slowdown of 64 bit code (x64) compared to its 32 bit counterpart

• 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.

  Such 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 code.

  

  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.

Other enhancements

New SIPS finally brought all features to the Telescope (mount) drivers and control tools. Beside basic functions (coordinates, goto, ...), it is now possible to control:

• Park and Unpark the mount, as well as SetPark position.

• 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).

The New FITS Header tool allowed manual, semi-automatic or fully automatic entry of some headers:

• 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 acquisition.

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.

Camera tool now supports guiding not only through guider camera with “AutoGuider” port, but also through a telescope driver, providing the driver supports PulseGuide interface.

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.