Jag testade nu att dra ner antalet processorkärnor åt Remix OS från 4 till 2, och det går fortfarande fort. Med 32-bitsversionen blir vardera väntetiden i BankID-appen för mig med 2 kärnor kanske 5 sekunder, och med fyra kärnor hälften av det, 2-3 sekunder, tror jag. (Det är svårt att mäta tiden exakt då det går så fort.) Det ska jämföras med
en dryg halvminut eller så då jag kört med bara
en kärna åt Remix OS.
Den kritiska förbättringen sker alltså då man ökar från en till
två kärnor åt Remix OS. Och anledningen till
det är med all säkerhet klantig programmering – gissningsvis av klåparna hos Finansiell ID-Teknik.
Vid programmering för multitaskande och multitrådade system är ju A och O att man ser till att en process eller tråd som saknar uppgifter lämnar över till systemet (som då ges tillfälle att släppa fram andra trådar och processer). För det finns särskilda systemanrop som låter en process/tråd vänta på någon händelse eller en viss tid. D.v.s. exekvering av tråden upphör helt tills angivet kriterium är uppfyllt. Ett slött och uselt alternativ, kallat
"busy-waiting", är att låta en tråd, som t.ex. väntar på att en annan tråd ska bli klar, bara köra en loop som konstant testar läget. (Är det klart nu? Nehej, men nu då? Nämen nu då? ... osv.) Tråden drar alltså 100% processorkapacitet utan göra någonting vettigt alls.
Med två kärnor i processorn märker man nog oftast knappt om en tråd eller process på detta usla sätt låser den ena (om inte två trådar samtidigt beter sig så illa, förstås). Men med bara en processor(kärna) ges andra trådar och processer inget utrymme alls – annat än vid av systemet forcerad växling till dem. Vilket rimligen är förklaringen till det beteende vi har observerat hos Finansiell ID-Tekniks BankID-klient v7 i Remix OS.
________________________________________
(Även om det alltså funkar utmärkt med två kärnor fortsätter jag för egen del att ge alla fyra fysiska kärnor jag har åt mina virtuella maskiner, eftersom jag, som sagt, inte ser någon nackdel med det.)