Spiky and Flat Dynamic Profiles

September 18, 2018

Dynamic profiles are central to the field specialization process. Runtime profiles are used in the first five steps in the Field Specialization process to identify attractive specialization opportunities, by successively narrowing down the scope to individual functions or even blocks or individual lines of code within those functions.

 

A spiky dynamic profile, with some functions contributing a significant percentage of the total runtime (and the remaining functions each contributing very little, say less than 1%), are prevalent, in our experience of field specializing four open-source and four proprietary DBMSes.

 

A flat dynamic profile, with all the functions having a low percentage of the total runtime, is less common.Such profiles arise from one or both of two situations. The first is encountered when the workload from which the dynamic profile is produced has complex queries that utilize many relational or columnar operators; for such workloads, the set of functions that implement each operator will contribute but a small portion of the runtime.

 

The second way in which a flat profile may emerge is aggressive delegation, in which each function has one goal, delegating much of the specific tasks needed to accomplish that code to narrower functions, which also delegate even narrower tasks. Doing this throughout the DBMS can lead to a flat profiles.

 

Both situations are amenable to field specialization. The query evaluation plan of a complex query will contain many operators. An example is MonetDB, a columnar store where each relational algebra operator corresponds to a MonetDB Assembler Language (MAL) instruction. (We examine this open-source DBMS here because it exhibits both phenomena and thus provides relevant examples.) Between 16 and 28 distinct MAL operators are used in each TPC-H query. Each function invoked in executing these MAL programs would contribute only a small fraction of the total elapsed time.

 

However, our experience is that invariants are found in many of the MAL instructions, often the same kind of invariant for a set of MAL instructions, meaning that the same or similar specialization can be employed across these related instructions. Also, a specialized MAL instruction, or function called by that instruction, can be invoked by several queries. The result is that a specialized function may be invoked by multiple queries in a workload or even by multiple operators in a query plan.

 

Another cause of flat dynamic profiles, that of aggressive delegation, results in many small functions within the DBMS source code. MonetDB includes a total of 2030 distinct MAL instructions, some with the same name but different signatures, over 755 distinct MAL instruction names. Our experience is that invariants are found in many of the MAL instructions, often the same kind of invariant for a set of MAL instructions, meaning that the same or similar specialization can be employed across these related instructions. Also, a specialization of a function on a collection of invariants can sometimes inline function calls, when the inlined function also exhibits some of those same invariants.

 

The result is that flat dynamic profiles are still very much amenable to field specialization.

Please reload

Featured Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Recent Posts
Please reload

Archive
Please reload

Search By Tags
Please reload

Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

© Dataware Ventures, LLC / T 520.490.4843 info@datawareventures.com /      designed and powered by BlueDream

  • LinkedIn Round
  • Twitter Round