Hello, everyone. It's my pleasure to be here and talk to you in front of you. I'm going
to talk about reduced precision and scientific computing and the main concern here is the
accuracy and keeping the improvement about the speed up. So, many scientific applications
they are highly dependent on the linear algebra computation and often we are considering
FB64 as something accurate. But nowadays we are seeing that many GPUs are providing
reduced precision with huge amount of the floating point operation. So, we are interested
to use that and provide something with good accuracy. The first thing that is coming
to the mind about the reduced precision is that start to computation find the first solution
somehow good quality and after that start refining that. For that reason I was reading
a paper and then I was thinking maybe can I replicate that experiment and see what
happened if we forget the initial solution that provided by reduced precision and just
use some random numbers as the initial point. I did that and I got some interesting result.
Almost the accuracy for forward error which means that how we are close to the correct
solution and backward error means how much modification we need in the initial data
to reach to the final solution. They were very similar to each other. You can see them here.
They have a similar magnitude of order and in that part even random initialization is
better. And that point is for backward error every little different but I think we can
consider them very close to each other. And about timing here I have implemented this
idea in MATLAB. So, is the simulation is not real timing but we have to pay for that.
So finding a first solution in reduced precision is costly is not free. So I am going back
with this idea. We have this possibility with the GPU how we are able to use that. So the
geometry with perspective is finding the intersection between hyperplans to find the solution
of the linear system of equation. And how we are implementing that is the classical
way that we are seeing LAPAC package. First we have to do the panel factorization. And
based on that we have to use the DTRSM and DGM. Those two are really good parallel but the other
one which is panel factorization is not because for keeping the accuracy every time we have
to check the column finding the maximum value and reordering the columns. But the rest of them
is GEM and GEM is very good implemented by the GPU. So the idea is that okay send the
panel factorization to the CPU and during the performing the trailing update you can compute
this one. So somehow you will go in parallel and get the solution as fast as possible.
That idea is very dependent to the sensitivity of the architecture that you are using. If you have
a super fast GPU, some slow CPU and problem is between connection, you are losing the
time and the collaboration is not working. So it is better to keep everything inside of the
GPU and here is a test you can see up to 4 times we can get improvement. So now how we are
able to make this part faster. I am going to talk about the fast life short life and normal life.
Imagine you are able to live two times. The first time you can see the consequence of your decision
and based on that for your normal life you can forget over thinking and just do your life in easy way.
So we are going to use that concept for computation and instead of doing just once,
do it twice. It is more costly, more data movement. But since we are changing the type of the
algorithm we are able to get more benefit and get it something faster. So first we are finding the
pivot list and then you are performing the algorithm without pivoting because of that concept
we are not looking for the pivot anymore. So we can just perform the final factorization
for the top square part of the panel and using the TRS M which is somehow jammed for the rest
of that. So we are increasing the possibility to run most of the part in parallel way.
And by reducing two FV16 we are able to load four times more data in the GPU and find the pivot
for larger metrics. We are introducing several algorithms. One of them is XPRP which is using
mix of FV32 and FV16. The other one is completely half version which is HPRP and the other
one is MPF that two versions are applying the pivot list to the whole metrics. But this one
is considering the panel and is just finding the panel pivot of the panel. So let's see
how they are accurate. If we use the PRP for the whole metrics after some dimension we can see
that we are losing accuracy. For example, for HPRP after 4K for XPRP which is mixed but for
whole metrics after 20K but for MPF the accuracy that we are obtaining is identical to
double precision. And let's see about the timing. Depending on the architecture,
somewhere we are able to improve and somewhere no. For example for this one which is
belong to the workshop GPU, we are able to get improvement for smart-sized metrics. That one is
for A100. For larger dimension we are able to get improvement because the type of the cache and
architecture completely different and that one also is related to the RTX 3090. The behavior is
similar to the waltz. And that's it. Thanks for listening.
All right. You might actually face the big early so there's at least time for one question.
We have any questions over your question. No.
I think we can apply that. You are asking me what will happen or how we are able to apply
that method to esports metrics. Esports metrics are coming from real world application and
you can see some elements are very large, some of them are very small. So you should consider
that to normalize the data before starting this. To avoid having very large because in FB16
we are not able to keep very large numbers. This is one consideration and another one is that
I think we are able to apply this method to multipron 12 metrics is because we can consider
each part of that metrics as a panel and apply the MPF method over that.