Stickybit

Software development

Everyone at Stickybit shares a vivid interest for all aspects of software. Strong programming skills is a corner stone in our competence and a readlily available tool in all possible situations and assignments. Or more succintly put: we love to code!

It takes a lot more than enthusiasm to produce and ship high quality software. To create an environment that produces the right results at the right time and with the right quality, you will require a good and clearly communicated process that is supported by a closely integrated development environment. Once you got that, you need strong domain competence and the right specialists for critical technologies.

Among our favourite programming technologies are J2EE and Spring. As our company is brimming with Linux-people, low level, embedded or Operating System's programming is in our very heartstrings. The third choice to make the cut is Python which we use for everything from scripts, prototyping and integration.

The development environments we create and work with differ depending on circumstances. Common characteristics for them all is a strong CM plan, transparency throughout the project life cycle with solid requirement driven test harnesses, continous integration and profiling. We choose the right tools and if something important is missing, we will create them.

Our domain competence spans over such diverse subjects as compilers and code generation, Domain Specific Languages. DSL, Large scale ICT Architectures, Unix like Operating Systems, Embedded development and Post Mortem forensics, Version Control and Configuration Management, Programming Methodology, Security, Data base modelling, Multi tier architectures, Open Source, Java/J2EE, Spring, TCP/IP and much more.

We love to share our knowledge and experience and we are no strangers to provide training and classes. The will to share our know how characterizes how we work as consultants and it is not uncommon that we work as mentors or thetechnical leads.

Cases

Optimizing simulator's execution time

This case is a story of how Stickybit found a way to turn a worrying situation regarding performance of the system's simulator at a customer's site into a costs and time saving optimization that eventually increased throughput of the entire department. The customer was in fact so pleased that it let our engineer use some of his results in a paper for his (long overdue) master thesis. This is his story.

A simulation and verification department within a large company made use of a simulator written primarily in C++. It was strongly suspected that optimizations were possible in this simulator, as most of the developers responsible for the simulator were not domain experts in programming (most had a strong background in other fields, such as signal processing). Beyond the general suspicion, however, there was not much knowledge or evidence available about the nature of any specific improvements that might be made. Since an individual simulation could take between several hours and several dozen hours, even a modest improvement of 5% execution time would save considerable resources.

Therefore, the assignment with the client was to first analyze and profile the simulator, to discover the location and scope of any execution
bottlenecks. After identification of the problematic portions of code, an analysis would then be made about any possible improvements and/or
alternative implementations to lower execution cost.

Multiple profiling tools were evaluated for usage in this assignment, including both open source and proprietary software. The former
included gprof (part of the gcc compiler suite), cachegrind (a memory profiling modification of valgrind), and oprof (a Linux kernel-based
profiler). The latter focused primarily on quantify, part of the IBM Rational PurifyPlus suite.

Due to the sheer size and runtime of the simulator, it became quickly apparent that any profiling tool with significant (>= O(n)) execution
overhead would not be feasible for general usage. This unfortunately ruled out the tools with the best visualization support, Rational
Quantify and cachegrind. Cachegrind had an overhead of 5-20 times standard execution cost, whereas Quantify's overhead was between 5-10
times cost from empirical testing. Gprof, conversely, had an execution overhead that seemed to be closer to logarithmic and could
provide nearly the same level of detail as quantify (minus the graphical user-interface/visualization support).

Application profiling via gprof revealed several execution bottlenecks in the simulator. Most interesting was that in the majority of cases, the code was not expected to be on the critical path of the application profile. In some cases, the cost was due to a suboptimal implementation
of basic datastructures (queues where data was copied as opposed to pointers updated), and in other cases due to the use of the wrong
datastructure (queues instead of a circular buffer).

One notable improvement was found in such an unexpected part of the simulator. There were cases where suboptimal standard c-library math functions were used where a specialized use case could imply a specialized implementation for optimal performance. One such example was the use of the standard pow() function for calculating integer values of two within a relatively small range of -32 to 32 for specialized quantization functions. An alternative implementation made use of lookup-tables of pre-calculated values. This improvement alone resulted in a surprising speedup of 12% for typical simulations. For the average performance regression simulation this single improvement was equivalent to a savings of between 30 minutes and 60 minutes running time.

Additionally, along with the profiling assignment came a certain level of code review, which revealed a number of bugs and coding oversights, the fixes for which were incorporated into the simulator as part of the audit (but not counted towards the overall speedup)

Further possibilities for improvement were found elsewhere in the simulator, such as the speed improvements to the random number generator, the memory management system, and targeted use of function inlining and class templating. The delivered improvements reached approximately 15-20% with an additional set of recommendations for a possible 35% total improvement.