Making software better and faster.In the past six years we have helped out various customers solve their software performance problems. While each project has been very different, there have been 8 reasons to hire us as performance engineers. These can be categorised in three groups:
Let’s go into each of these.
When people hear about Software Performance Engineering, the first thing they think about is reducing processing time. The largest part of our customers have hired us for this task, but all had different time-requirements.
The most usual type of project has very specific timing-requirements. Some examples:
We did not only use GPUs (OpenCL or CUDA) to make our customer’s code faster, but also redesigned algorithms to be more efficient. In a few cases we could get the timing-requirement by optimising the code – there was no need to port to the GPU anymore.
Getting hours to minutes or minutes to seconds.
When employees are waiting for the computer to finish, this reduces efficiency. Some examples:
We found that users feel less powerless when pressure increases, as they have more control of the time and the software. Before the speedup they felt controlled by the software.
From seconds or even minutes to milliseconds.
When a system does not react immediately, trust in the system goes down. Some examples:
Besides standard performance engineering, there are more options to make the user interaction more immediate and snappy. For instance a “low resolution” result can let the user preview the results.
Getting from seconds to milliseconds, or from milliseconds to microseconds.
Where responsiveness deals with users, latency describes automated systems where microseconds matter. The requirements to maximum processing time are often very strict and real-time operating systems could be used. Some examples:
We choose FPGAs when the latency needs to be in the low microsecond, and GPUs when latency has to be in the millisecond range. Work we did here included porting from CPU to GPU and from GPU to FPGA.
The goal in this category is the same as the previous, but the problem is described often from the perspective of features and data size. This is because the time is not seen as a current problem, but as a future problem.
Same processing time, more functionality.
The processing time is described as a disadvantage, but is not a complaint – there is understanding the computations are intensive. On the other hand the customers request extra features. Some examples:
In cases where we also improved the existing software for performance, total processing time for more data went down.
Same processing time, tenfold the data.
Each year the data size increases more than the performance of computers increase. Where a single server was enough 3 years ago, now a small cluster has to be rented.
To cope with this explosive growth we are asked to remodel the software that ports well to current end future high-performance processors. Some examples:
This is the most common type of problem we solve in this category. Especially proven-to-work models (including prototypes) are chosen to work on larger data sets than they were designed for.
When the operation scales up, the operational costs can increase exponentially. Some of our customers identified the problem werll in advance and let us reduce their operational costs before it got out of hand.
Same performance, less hardware.
Processing data can take 10s to 100s of servers, increasing power and maintenance costs and thus lowering the performance/€ or performance/$.
We’ve helped early scale-ups who identified the problem of the operational costs sky-rocket when the code is not optimised.
Same performance, less Watt.
It’s all about performance/Watt. Some examples:
Reducing power usage on portable devices has been the most common use case here.
Call or email us to start discussing your problem. In a one week effort of analysing your code and discussing with the developers, we can often provide a good indication how much time the performance improvement can take.