I benchmarked DFP extensively when it was first released (decades ago now). For functional equivalency (same precision in result) it is 100x faster than the best non-DFP optimized implementation. For instruction equivalency, it is slightly faster than HFP and BFP. There was no condition when DFP was slower. Over the years DFP implementation has improved so there may well be greater performance benefit for modern machines. Normally it is Packed Decimal that is being replaced by DFP, for the increased precision, and DFP is always faster than PD. For most commercial applications the cpu usage for numeric computations is not significant, but accuracy of result is important particularly in countries with lots of zeroes like Korea and Indonesia :)
On Thu, Mar 23, 2023 at 5:46 AM René Jansen <rene.vincent.jan...@gmail.com> wrote: > When we compare the DFP instructions to the 'old' floating point > instructions, we can see that these were storage-to-storage type > instructions, while the new set is register-to-register, which can make an > enormous difference with fast instruction caches and -pipelines -- this is > why my C code is faster than my assembler code, because the compiler > chooses the latter type over the storage-to-storage ones. The DAT box might > have done its work, but the data is still in memory and not in the cache. > On a heavily loaded transaction system, you are of course doing millions of > these a second, on a lot of CP's and ZIIP's, specially in financial > environments - this is where BigDecimal is more or less mandatory as a > currency data type. > > So I am setting up a few benchmarks, and I will report back. But the first > question is, how does it work? Java does not have a normal compiler > backend, where we can tell it to compile for a certain ISA (or default to > the one it is on - but non-Java workloads are seldom compiled on the same > LPAR) . We cannot have a driver that decides which fork of the code to > take, depending on the hardware. The instructions are actually coughed up > by the JIT whenever it is decided that it would benefit, which means they > would be faster than interpreting. It could be, of course, that the runtime > of the Java libraries, is already precompiled in the right instruction. > That is probably where I am going to look first. But if most of it is > called from libraries, it cannot inline the instructions, which would get > rid of a lot of the performance gains. I hope this is documented somewhere > apart from the source code, which might not even be open. > > best regards, > > René. > > > On 22 Mar 2023, at 18:18, Colin Paice <colinpai...@gmail.com> wrote: > > > > The difference may be down at the noise level - unless you are doing > > millions of these a second. > > For example if you had a *load register,address* in a tight loop- the > > second time may be much (100?) faster because the conversion of virtual > > address to real page address will already be done, and the data will be > in > > the processor cache and so does not need to be read from RAM, or a > > different book etc. > > I found using a stack rather than a malloc in each function gave more > > benefit than trying to polish the instructions. > > Colin > > > > On Wed, 22 Mar 2023 at 17:03, René Jansen <rene.vincent.jan...@gmail.com > > > > wrote: > > > >> That's another interesting take; but I have to be sure that it is used > >> before I declare the winner. > >> > >>> On 22 Mar 2023, at 18:00, David Crayford <dcrayf...@gmail.com> wrote: > >>> > >>> I can't answer you original question but I doubt if DFP is really that > >> much faster. I would imagine it's implemented in millicode and not > silicone > >> so is a software implementation at heart. I would be surprised if it > beats > >> BigDecimal on a PC but I could be wrong. > >>> > >>> On 23/3/23 00:42, René Jansen wrote: > >>>> Without reading any documentation (sorry!), the issue at hand is this. > >> I want to show the performance gains of using DFP (Decimal Floating > Point) > >> for the typical financial application, after I noticed at some other > client > >> their bought packages seldom were compiled using the right compiler > options > >> (some could have run in 1966 or so - well I exaggerate, but a Z9 would > not > >> have been a problem). > >>>> > >>>> This is for Java applications, and it proves slightly harder than I > >> thought. I don’t have object modules to disassemble and while I can do > >> -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly on my mac or any Linux > >> box, IBM’s J9 seems to ignore these altogether. For Linux and the mac > there > >> is a .so (or .dylib) that even disassembles what you’d otherwise are > shown > >> in hex - https://chriswhocodes.com/hsdis/ which is called hsdis but > what > >> I would not upload to other people’s machines lightly without building > it > >> myself. > >>>> > >>>> Does anybody know how to ask the J9 (Java 8) on z/OS how to show me > >> what it does when the JIT decides native code would be best? > >>>> > >>>> many thanks in advance, > >>>> > >>>> best regards, > >>>> > >>>> René Jansen. > >>>> > >>>> > >>>> > >>>> ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
