Street Credit FP Due Diligence

Question:

Over/Under: 12 seconds of floating point computation; P&L and risk for several 100K default swaps; off the shelf servers in 2012 – running standard ISDA CDS model code; 5 to 6 decimal place tie out?

Even for non-SNAC positions I’m thinking under, perhaps epically under depending on the hardware budget.  Ideally you run code to determine this and we do not have the optimized code in hand, but we can write it. Before writing the code you want to run the due diligence to see if writing the code is worth it. Let’s see.

History:

We recall from previous 2009 estimates ( see Totally Serial) for unoptimized scalar code cooking of par and perturbed curves certainly costs less 7 milliseconds and valuation of a default swap’s contingent and fee legs take about 40 microseconds . This is of course assuming that the default swaps have custom cashflows and are not SNAC default swaps (standard instruments with IMM date cashflow schedules) in which case the default swap valuation execution time massively collapses and the credit curve cooking time can be significantly reduced as well.

Methodology:

Let’s assume 100K OTC (non SNAC default swaps) and 10K credit curves and we can scale to fit the actual curve and deal counts with more accurate estimates. Lets further assume that the 10K credit curves are independent (there is no known geometric or arithmetic structure to the traders marks). So, you actually have to cook each of the 10K credit curves. For unoptimized code then we expect about 7 ms*10K + 0.04ms * 100K or ~80 seconds floating point computation elapsed time on a single contemporary microprocessor core.  Naively, you would guess this benchmark optimization would be looking for about 20-30 seconds  (performance improvement 3x-4x over unoptimized) on a single x86 core.  So assuming we buy a $3000 6-8 core microprocessor in 2012 the 100K/10K batch optimized fp code executes in a few seconds, expected case. Variance in the estimate will depend on some assumptions like the average number of iterations for convergence with Brent, the average term of the default swaps, the number of perturbed credit curves needed for full risk, the scaling across multiple on-chip cores among other things.

Amdahl’s Law directs the due diligence to first focus on the curve cooking so that’s what we will do in addition to rechecking the previous estimates ( I think they were very conservative) in the outlined argument. Lets count the operations in the ISDA code to nail this estimate down.  Then we will estimate what the L1 and L2 cache efficiency we can plausibly expect to get a target due diligence number. What do we look at in the ISDA src distribution? Bunch of src files we don’t care about (DK) from the perspective of getting an estimate of the floating point computation time. The other annotated file names (in bold) contain source we may need to study.

ISDA CDS Model v1.7

• badday.c                         DK
• bsearch.c                       DK
• buscache.c                    DK
• busday.c                        DK
• cashflow.c                    DK
• cds.c                             computes contingent leg, fee leg, vanilla CDS PV
• cdsbootstrap.c        Brent root finder for credit curve cooking
• cdsone.c                      converts upfront to flat spread
• cerror.c                           DK
• cfileio.c                           DK
• cfinanci.cpp                   DK
• cmemory.c                      DK
• contingentleg.c         computes contingent leg and one period integral
• convert.c                         DK
• cx.c                                   DK
• cxbsearch.c                    DK
• cxdatelist.c                     DK
• cxzerocurve.c            calc zero price for given start  and maturity
• date_sup.c                      DK
• dateadj.c                         DK
• dateconv.c                      DK
• datelist.c                         DK
• dtlist.c                             DK
• feeleg.c                         calc PV of single fee, fee leg, accrued
• fltrate.c                           DK
• gtozc.c                          looks like curve cooking
• interpc.c                     interpolation of rates
• ldate.c                             DK
• linterpc.c                    curve interpolation
• lintrpl.c                         DK
• lprintf.c                         DK
• lscanf.c                         DK
• rtbrent.c                     root finding for curve cooking
• schedule.c                 possibly DK – cash flow schedule generation
• streamcf.c                 calculate cashflows
• strutil.c                          DK
• stub.c                           stub payments
• tcurve.c                       discounting
• timeline.c                   not sure maybe DK
• version.c                        DK
• yearfrac.c                       DK
• zcall.c                            zero curve
• zcswap.c                      add strip of swap to zcurve
• zcswdate.c                      DK
• zcswutil.c                    cashflow lists for swap instruments
• zerocurve.c                 build zero curve from mm and swaps
• zr2coup.c                     calculates the par swap rate
• zr2fwd.c                        calculates zero coupon forward rate

We should be able to pound this due diligence through with a little effort, let’s see how it goes. Maybe I am missing something? It’ll take a couple postings I expect, but it will be interesting.

Advertisement