[GiNaC-list] Performance of simplify_indexed on long chains of Dirac matrices
Vladyslav Shtabovenko
v.shtabovenko at tum.de
Tue Jan 6 02:04:44 CET 2015
Dear Vladimir,
for the optimization strategy I would have a look at what FORM does.
The algorithm is described here
<http://www.nikhef.nl/~form/maindir/documentation/reference/online/online.html#gammaalgebra>
and the corresponding C code is available on GitHub:
<https://github.com/vermaseren/form/blob/master/sources/opera.c>
Cheers,
Vladyslav
Am 04.01.2015 um 20:36 schrieb Vladimir V. Kisil:
>>>>>> On Sun, 04 Jan 2015 18:53:51 +0100, Vladyslav Shtabovenko <v.shtabovenko at tum.de> said:
> VSh> 1) By repeatedly applying the anticommutation relations to move
> VSh> g_mu through all other matrices to g^mu. This is the easiest
> VSh> but also the slowest way to implement.
>
> This is what GiNaC is using, as far as I understand.
>
> VSh> (people mostly care only about traces), it might be reasonable
> VSh> to look at the performance of dirac_trace instead.
>
> IMHO, this routine still uses clifford::eval_ncmul(), which I think
> is the principal bottleneck.
>
> VSh> takes around 5 seconds on my machine, a similar code with FORM
> VSh> requires less than 0.01 seconds. With FeynCalc
>
> Probably, GiNaC will never do a particular task as good as
> a specialised software. GiNaC allows to mix all types of objects in a
> single expression, so all simplifying algorithms need to be of a very
> plain generic nature.
>
> VSh> So I think that it would be very nice if someone of the GiNaC
> VSh> developers could have a look at this issue.
>
> I am not familiar with Dirac matrices close enough to optimise the
> performance beyond the simple anticommutation. It will be good if you can
> come with some optimisation suggestions of clifford::eval_ncmul().
>
> Best wishes,
> Vladimir
>
More information about the GiNaC-list
mailing list