Hi everyone.

I'm attend the SKA conference in Auckland next week and I would like to discuss a opportunity for the D community.

I am based in Wellington, New Zealand.  In Auckland, NZ, from Tuesday to Friday next week there will be two seminars held.

The first 2 days (Tuesday and Wednesday) are for the multicore conference. Details are   http://www.multicoreworld.com/

Here is the schedule for 2 days (thursday & friday) of the SKA conference:

http://openparallel.com/multicore-world-2014/computing-for-ska/schedule-computing-for-ska-2014/


John Gustafson Will be presenting a Keynote on Thursday 27th February at 11:00 am

The abstract is here:  http://openparallel.com/multicore-world-2014/speakers/john-gustafson/

There is also a excellent background paper, (PDF - 64 pages) which can be found here:

http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf

The math details are beyond me, but I understand his basic idea.

I would like to bring your attention to Page 34 and his comments re "standard committees"  and page 62 and his comments "Coded in Mathematica  for now. Need a fast native version.."

I am sure you can see where I am going with this ....

1.  Would it be possible to implement the "unum"  representation in D and therefore make it a  contender for the SKA ?

2.  Is there any interest in this format within the D community

Destroy.

Nick

On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
>
> Hi everyone.
>
> I'm attend the SKA conference in Auckland next week and I would like to discuss a opportunity for the D community.
>


Sorry if I was not clear what the SKA is. In a nutshell is a truely massive telescope project which will require massive computing resources.

https://www.skatelescope.org/

Nick

On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
>
> Hi everyone.
>
> I'm attend the SKA conference in Auckland next week and I would like to discuss a opportunity for the D community.
>
> I am based in Wellington, New Zealand.  In Auckland, NZ, from Tuesday to Friday next week there will be two seminars held.
>
> The first 2 days (Tuesday and Wednesday) are for the multicore conference. Details are   http://www.multicoreworld.com/
>
> Here is the schedule for 2 days (thursday & friday) of the SKA conference:
>
> http://openparallel.com/multicore-world-2014/computing-for-ska/schedule-computing-for-ska-2014/
>
>
> John Gustafson Will be presenting a Keynote on Thursday 27th February at 11:00 am
>
> The abstract is here:  http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
>
> There is also a excellent background paper, (PDF - 64 pages) which can be found here:
>
> http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
>
> The math details are beyond me, but I understand his basic idea.
>
> I would like to bring your attention to Page 34 and his comments re "standard committees"  and page 62 and his comments "Coded in Mathematica  for now. Need a fast native version.."
>
> I am sure you can see where I am going with this ....
>
> 1.  Would it be possible to implement the "unum"  representation in D and therefore make it a  contender for the SKA ?
>
> 2.  Is there any interest in this format within the D community
>
> Destroy.
>
> Nick

Hmm. Interesting. It could be done in D, definitely.

However, I'm a bit skeptical on how efficient it would ever be without specialist hardware. I'd have to read it over a few more times to get a proper grip on it.

On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
>
> Hi everyone.
>
> I'm attend the SKA conference in Auckland next week and I would like to discuss a opportunity for the D community.
>
> I am based in Wellington, New Zealand.  In Auckland, NZ, from Tuesday to Friday next week there will be two seminars held.
>
> The first 2 days (Tuesday and Wednesday) are for the multicore conference. Details are   http://www.multicoreworld.com/
>
> Here is the schedule for 2 days (thursday & friday) of the SKA conference:
>
> http://openparallel.com/multicore-world-2014/computing-for-ska/schedule-computing-for-ska-2014/
>
>
> John Gustafson Will be presenting a Keynote on Thursday 27th February at 11:00 am
>
> The abstract is here:  http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
>
> There is also a excellent background paper, (PDF - 64 pages) which can be found here:
>
> http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
>
> The math details are beyond me, but I understand his basic idea.
>
> I would like to bring your attention to Page 34 and his comments re "standard committees"  and page 62 and his comments "Coded in Mathematica  for now. Need a fast native version.."
>
> I am sure you can see where I am going with this ....
>
> 1.  Would it be possible to implement the "unum"  representation in D and therefore make it a  contender for the SKA ?
>
> 2.  Is there any interest in this format within the D community
>
> Destroy.
>
> Nick

It looks like something that could be made into a library, with the help of inline assembly.

Shame I've got study next week. Definitely no chance of making it.

This is very interesting, thank you for sharing this. My knowledge of assembly, compilers, and how machines actually work is limited, but I knew enough about the details of floating point to get the gist of it. The diagrams in the PDF also helped. I hope someone does more research on this, as it looks promising for improving the quality of calculations.

Slide 6:

>Even the IEEE standard (1985) made choices that look dubious now<

On the other hand it's still working surprisingly well today.


> Negative zero. (ugh!)

It's not bad.


Slide 15: are (Page Rank and) mp3 Players using floating point values?


Slide 18: "is harder than doing THIS with them?" Hardware multiplication uses a different algorithm.


Regarding the variable length of his FP numbers, their energy savings are beer-based numbers, I don't think they have any experimental basis (yet).

Bye,
bearophile

> Regarding the variable length of his FP numbers, their energy savings are beer-based numbers, I don't think they have any experimental basis (yet).

Also, because they are variable sized, you need to access them through pointers if you want random access. Now you are reading both the pointer and the value from memory. Since pointers and double precision floats have the same size on modern hardware, one would expect this to actually consume more energy than just reading a double precision value. An additional indirection can also have great performance cost. And there's one more step you need to do. After getting the pointer you need to first read the utag so you can decide how many bytes to read.
So where you would normally just read the value, you now need to read the pointer, use that to read the utag and use the utag to read the value.

On 20 February 2014 15:26, bearophile <bearophileHUGS@lycos.com> wrote:
> Slide 6:
>
>> Even the IEEE standard (1985) made choices that look dubious now<
>
>
> On the other hand it's still working surprisingly well today.
>
>
>> Negative zero. (ugh!)
>
>
> It's not bad.
>
>
> Slide 15: are (Page Rank and) mp3 Players using floating point values?
>

Most encoding formats use a form of discrete cosine transform, which involves floating point maths.

On 2/20/2014 2:10 AM, Nick B wrote:
> 1.  Would it be possible to implement the "unum"  representation in D and
> therefore make it a  contender for the SKA ?

Yes, as a library type. I don't think it'll save any energy, though.

> 2.  Is there any interest in this format within the D community

I think it would be a fun and useful project. Any takers?

(Be aware that there's a Python 'unum' type that is something quite different.)

Iain Buclaw:

> Most encoding formats use a form of discrete cosine transform, which involves floating point maths.

I don't believe this much :-(

Bye,
bearophile