REAL(16) - long double

[jimdempseyatthecove]

Are there any plans to implement the IEEE X_floating point (16 byte) with SSEn.m instructions?

Although this might not be suitable for mainstream (desktop) computing, it would be suitable for premium priced products. Intel does have premium priced product lines e.g. mmm Extreme. You could lable it at mmm Extreme+ and double the price.

Jim Dempsey

[capens__nicolas]

Quoting - jimdempseyatthecove

Are there any plans to implement the IEEE X_floating point (16 byte) with SSEn.m instructions?

Although this might not be suitable for mainstream (desktop) computing, it would be suitable for premium priced products. Intel does have premium priced product lines e.g. mmm Extreme. You could lable it at mmm Extreme+ and double the price.

Jim Dempsey

Why not emulate the format? For the prize of such exclusive hardware you could probably buy a multi-socket system with comparable throughput.

[jimdempseyatthecove]

Emulation of the format will be much slower than inclusion of the 16-byte format in the SSE instruction set.

SSE has almost all the functionality to perform the 16-byte IEEE FPmath functions. SSE has 16 byte data path and 16 byte manipulation instructions but not the entire set necessary to efficiently implement real(16) math. The inclusion of the 16-byte format could potentially be done with a firmware change inside the processor without requiring a change in the design of the data paths. With the current SSE instruction set it is inefficient to perform 128 bit (112 bit) shifts and rotates. Note, the change would require no change in operating system to support the instruction extension. As an interrum measure, 16-byte integer math could be implemented. This would eliminate the bit barrier between the double quads.

Jim Dempsey

[capens__nicolas]

Although SSE already offers 128-bit registers and you're probably right that it doesn't require any O.S. change, I wouldn't go as far as saying the datapath is already in place. An 128-bit multiplier would be four times larger in circuit area and have twice the latency of a 64-bit multiplier (give or take depending on the actual design). So don't underestimate the hardware implications. This certainly can't be done with a simple firmware/microcode update. It would require a substantial amount of R&D and unless Intel would see any big reason for dedicating a lot of transistors to this it would be significantly slower than 64-bit doubles.

Why would you want support for this anyway? A 64-bit double is accurate enough to measure the height of a mountain in nanometers, from the center of the earth! By the way, x87 actually does support a more accurate format, namely 80-bit extenced precision or long doubles. I would use either that or emulation, before expecting Intel to make the tradeoffs for a hardware implementation.

[PabloJr]

"Why would you want support for this 16-byte long double? " Because in the Arm64 processors that are used in Android tablets, 16-byte long doubles are already implemented. So instead of using my Intel laptop to do numerical analysis, I am forced to use gcc on Termux on my Android tablet. I had to get an external keyboard, and that made development a bit better on the Android, but I sure would like lots of disk space to store my programs and data. The laptop is a better choice for this if only Intel had 16-byte long doubles.

[jimdempseyatthecove]

Although supporting full 128-bit FP may require excessive changes, supporting a few additional128-bit integer math functions might be incorporated without much extra effort. In particular you would like to be able to align the mantissas of two operands in preparation for addition. i.e. perform bit shift between 0 and 112 times in one instruction and inserting the implicit 1 and sign extension. The 128-bit add or subtract could then be performed. Then a normalize instruction to produce a delta exponent for incorporation into the prior saved exponent.

Accelerate most of the integer portion of an ADD/SUB. The biggest portion of the emulation using eax/rax... registersis in the rotation for the alignment. MUL and DIV would still loop 112 times but each iteration would consume significantly fewer instructioncycles. With a few number of extensions you could get considerable amount of performance boost. The thing to do would be to look at the source code of the REAL(16) math support routines and see what you need to give them a boost.

This is not important enough to me to bug Intel on this as I can mostly get by using REAL(8). In some of my simulation work I have to augment the position information with a floating reference point. e.g. Using a coarse position with respect to solar system barycenter then index using a finer position/velocity... of of that. Then occasionally perform reconciliations as the object of interest and moving reference point separate.

As an example, Pluto has a Aphelion orbital distance of 4,583,200,123 miles, or 24,199,296,649,440 feet. The dynamic range in feet would be approximately be twice this. If we consider the precision of a real(8) at 53 bits this means on the scale of the maximum dynamic range the precision reduces to an accuracy of ~0.005 feet. For planetary objects the precision is sufficient. However, when dealing with uncertainties of +/-0.005 feet the dynamics of lesser sized objects (e.g.artificial satellite)becomes problematic. As stated in the prior paragraph, the technique used to mitigate dynamics problems was to use a floating reference point.

Jim Dempsey

[capens__nicolas]

I already suspected this to be about something of "astronomical" proportions. Oh, and in the civilized world we measure in metric SI units, not body parts. ;)

Anyway, you can already do 128-bit shifts in a single instruction with SHRD and SHLD in x86-64. Adding and subtracting can be done with ADC and SBB in two instructions. 128-bit multiplication can be done with four 64-bit multiplications, and division is probably best done using the Newton-Raphson method (starting from a 64-bit division you can double the number of accurate bits in just one iteration). So everything you need to emulate it reasonably efficiently is already there I believe.

[jimdempseyatthecove]

>>Oh, and in the civilized world we measure in metric SI units, not body parts.

The civilized world is using a measurement that is known to be in error. The meter was defined before it was measured. The definition was 1/10,000,000 the length of a meridian from the North Pole to the equator. The French made a measurement of part of a meridian (that went through Paris) and estimated the remainder. The French got this number wrong, but didn't notice this until after a "standard measure" bar of platinum was produced. This "standard measure" bar is short about 0.2mm.

Meters or feet makes little difference, about 1.5 bits of precision. When you are handling small differences in large values the number of bits in the calculation is important. Although you can perform some mathematical gymnastics using floating/moving reference points, sometimes you stumble and the errors are harder to detect.

Jim Dempsey

[jimdempseyatthecove]

For illustrative purposes, if the 1790's French were to build a cannon to fire a cannon ball around the Earth (neglecting Coriolis effect) their cannon ball would fall short ~8,000 meters.

Jim Dempsey

[capens__nicolas]

Quoting - jimdempseyatthecove

The civilized world is using a measurement that is known to be in error. The meter was defined before it was measured. The definition was 1/10,000,000 the length of a meridian from the North Pole to the equator. The French made a measurement of part of a meridian (that went through Paris) and estimated the remainder. The French got this number wrong, but didn't notice this until after a "standard measure" bar of platinum was produced. This "standard measure" bar is short about 0.2mm.

That's only an error if you use the Meridional definition, which was only the standard from 1791 till 1795. After that the reference bar itself was the definition.

Feet was in practice still measured in body parts at that time, and later too. There were also tens of different highly inaccurate references in various countries. Thomas Jefferson proposed an (again, inaccurate) definition based on a pendulum, but it never even got legislated. Doing any sort of accurate scientific workin feetwas ridiculous. It only became somewhat usable after 1958when it wasdefined in terms of the meter.

Anyway, I never intended to turn this into a metric versus imerial discussion (since there really is no discussion). I was just surprised to see a scientist use miles and feet.

Aremy suggestions for 128-bit arithmetic useful to you for efficient emulation or do you require even higher performance?

[jimdempseyatthecove]

>>Aremy suggestions for 128-bit arithmetic useful to you for efficient emulation or do you require even higher performance?

All I am saying is the same arguments against supporting REAL(16) can be applied against supporting REAL(8). And then degrade the argument to REAL(4). Note, many of the GPU's, until recently, supported only REAL(4). It was pressure by those using GPUs for numerical intensive applications that drove the GPU vendors into supporting REAL(8). I am just a squeaky wheel.

Jim Dempsey