Stickybit

Mjukvaruutveckling

Vi på Stickybit förenas i ett brinnande intresse för alla aspekter av mjukvara. För oss är programmering en grundsten i vår kompetens och självklart redskap att ta till i alla möjliga uppdrag och situationer. Eller enklare uttryckt: vi älskar att hacka!

För att producera och färdigställa mjukvara krävs betydligt mer än entusiasm. För att få till en fungerande helhet som levererar rätt resultat med rätt kvalitet i tid så krävs först och främst vass domänkompetens, en bra process understödd av en sammanhållen utvecklingsmiljö samt rätt specialister för kritiska teknologier.

Bland våra favoritteknologier finns J2EE och Spring, vilka också är hörnstenar i vår egen produktutveckling av skiktade affärssystem. I ett företag fullt med Linux-människor är os-nära programmering i C självklarheter. Vill vi göra en prototyp har vi Python att tillgå.

Utvecklingsmiljöer vi bygger upp och arbetar i skiljer sig i olika sammanhang. Gemensamt för dem alla är en bra cm-plan, kontinuerlig genomlysning av projektets utveckling med testning, continous integration och profilering. Vi väljer rätt verktyg och saknas något bygger vi dem.

Vår egen domänkompetens som vi är extra stolta över omfattar kompilatorer och kodegenering, OS/hårdvarunära-nära programmering, säkerhet, databasmodellering, skiktade arkitekturer, Open Source, Java/J2EE, Spring, TCP/IP med mycket mera.

Vi delar gärna med oss av våra kunskaper och är vana vid att hålla utbildningar eller ge kurser. Viljan att dela med sig av vårt kunnande genomsyrar också hur vi fungerar som konsulter där vi ofta fungerar som mentorer eller technical leads.

Fallstudier

Utbyte av C-kompilator

Många i denna värld skriver kod men hur vet man att kompilatorn genererar maskininstruktionerna på ett korrekt sätt och vad gör man när det går snett? Denna fallstudie beskriver hur en av våra medarbetare axlat det tekniska ansvaret för utbyte av C-kompilator för embedded utveckling. En i teorin enkel uppgift att formulera men samtidigt en extremt krävande uppgift att garantera att kodgenereringen förblir korrekt.

Målsättningen är naturligtvis att erbjuda utvecklare en pålitlig miljö ur kodgenereringsperspektiv som ger korrekt kod med god prestanda, men hur kommer man dit?

Några problemställningar..

Hur kan icke-standardiserad funktionalitet som fanns tillgänglig i de tidigare verktygen översättas till de nya?

Varför ger den här dissassemblerade koden fel resultat trots att exakt samma källkod har fungerat felfritt med en tidigare kompilator/assembler/länkare?

Varför lägger länkaren viss kod eller data på fel ställe?

Hur undviks utrymmes- och tidskrävande kopieringar under initieringen?

Vår konsult tog löpande hand om utvecklarnas frågor relaterade till kodgenerering och
agerade som kundens länk till kompilatorleverantören och ägnade sig åt dagliga uppgifter som:

Kompilering och assemblering, inklusive identifiering av felaktig
kod (kodgenereringsfel) och dålig kod (prestandaproblem)
samt integration i byggmiljön

Länkning, exempelvis placering, initiering och symbolhantering

Objektkodsformat, inklusive översättare dem mellan

ABI-relaterade frågor som alignment, endianness etc

Programmeringsspråk. Vad ska man kunna räkna med från en ANSI/ISO
C-kompilator? Hur görs kod så portabel som möjligt?

Wrappers för att uppfylla gränssnitt i både C och skriptspråk

Skript för analys av output från utvecklingsverktygen.

En avgörande insats bestod i att etablerada en miljö som tillåter kompilering med olika kompilatorer för olika delar av kodbasen.

På så vis möjliggjordes gradvis övergång till en ny kompilatorsleverantör eftersom delar av kodbasen kunde anpassas till den nya kompilatorn utan att vara beroende av om andra delar av kodbasen genererats med den ursprungliga kompilatorn. Dessutom, genom att möjliggöra gradvisa förändringar så blir verifiering av korrekthet i genererad kod betydligt enklare att genomföra jämfört med om kompilatorn bytts ut för all kod samtidigt. Inte så dumt då utbytet införs i pågående projekt som kör för fullt.

Modelldriven kodgenerering

Vår uppgift var att utveckla ett nytt språk för beskrivning av hårdvara i syfte att automatisera delar av kundens utveckling så långt som möjligt samtidigt som graden av återanvändbarhet gentemot framtida projekt skulle ökas.

De viktigaste problemen som skulle elimineras var kopplade till konsistensproblem orsakad av att samma information hanterades med olika teknologier. Detta försvårade återanvändning och skapade stora problem vid granskning av storskaliga designer.

Tillsammans med vår kund har vi skapat en ny metodik för högnivåbeskrivning av integrerade kretsar. Metoderna bygger på en traditionell objektorienterad utvecklingsmetodik men går steget längre för att dels bättre passa de processer som används vid hårdvaruutveckling och dels för att stödja design av storskaliga arkitekturer.

För att stödja metodiken har Stickybit skapat ett domänspecifikt språk och ett ramverk i Java ämnat för generatorer. Språket är enkelt och lätt att använda samtidigt som det erbjuder konstruktioner med högre grad av återanvändning än i traditionella objektorienterade språk.

Implementationen består av design av utbyggbart språk, parsers och generatorer för att omvandla designspråket till kod i C/C++, VHDL, System Verilog och E-kod. Paketet levererades med utbildningsmaterial, tillse att plattformen förs ut i organisationen samt underhåll och support för slutanvändare.

Resultatet för kunden är vinster i produktivitet, ökad kvalitet och drastiskt reducerade underhållskostnader tack vare kvaliteten på datakonsistens.

Programmeringskurs i Python

På rekommendationer kontaktades Stickybit av ett IDEON företag som nyligen hade börjat arbeta med byggsystemet SCons för sina mjukvaruprojekt. Konfigurationsfilerna i SCons utgörs av script i programmeringsspråket Python och kunden såg nu fram emot att väsentligt förbättra sina byggprocesser.

Det fanns dock ett problem

att adressera innan den nya byggmiljön kunde tas i drift. Flertalet av utvecklarna i företaget som annars var vana embedded-utvecklare eller Windows-programmerare hade aldrig tidigare arbetat med Python. En av kundens medarbetare som tidigare kommit i kontakt med våra konsulter föreslog att man skulle ta in Stickybit och be oss att hålla en kurs.

Tillsammans med kunden

satte vi oss ned och analyserade behovsbilden. Det stod klart att kundens organisation snabbt behövde ta till sig en bred karta av teknologier och ramverk kopplade till Python för att tillgodogöra sig den fulla potentialen i satsningen på ny byggmiljö. Gemensamt tog vi fram programpunkter till en tvådagars kurs som skulle inbegripa för kunden kritiska ramverk och programmeringsspråket Python. Stickybits ansvarige betonade vikten av att kursen lades upp på ett sådant sätt att dess tredje dag, den då deltagarna återvände till sina ordinarie uppgifter är viktigast. Hela poängen är att tillföra ett nytt arbetsredskap i utvecklarnas vardag. Vi tycker att vår kurs blev mycket lyckad. Sedan dess har vi hållit den flera gånger för olika företag och den har utvecklats för varje nytt tillfälle. Nedan kan du läsa några av omdömena från vår allra första kurs:

Kompetent kursledare, visste vad han pratade om, entusiastisk
Ärlig och sa till när han inte visste något
Bra innehåll och upplägg på kursen
Bra att fokus mest låg på idiom och vad som skiljer python från andra språk
Bra med flera korta övningar som illustrerar hur idiomen tillämpas, så att man får lite hands on-upplevelse utan att lägga för mycket tid på att lösa rena programmeringsuppgifter
Trevligt upplägg i lokalen, bättre än lärare/elever bakom kateder/skrivbord som traditionella kursen kan vara
Alla är mycket nöjda och kursen levde upp till allas förväntningar

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.