Samma hÀr.
Snyggt! Jag skulle inte kalla det ett hemskt exempel. DÀremot har du en bugg pÄ rad 86, testar samma kombination tvÄ gÄnger. Jag upptÀckte ganska snabbt att det inte var nÄgra problem att skriva din variant nÀr jag testade att skriva ner den i kod istÀllet för att bara försöka koda i huvudet. Jag tror att jag hade hÀngt upp mig lite för mycket pÄ att jag ville göra en simd version av parsningen ocksÄ. Konstigt nog sÄg jag inte nÄn direkt skillnad i java trots att det Àr uppenbart att din version borde vara snabbare Àn min. Lösningen blev att skriva om min version till c++ istÀllet för att kunna jÀmföra bÀttre. (bara programmerat c++ ett par dagar förra pÄsken vilket Àr förklaringen till att koden ser ut som den gör). Tydligare skillnad i c++ dÀr din version ser ut att vara nÀstan 50% snabbare.
Men... jag passade Àven pÄ att skriva om parsningen till simd för att visa det jag Àr ute efter. Parsar tvÄ rapporter Ät gÄngen. Egentligen kan man skippa nÄgra steg om man mmap:ar filen istÀllet (vilket jag inte orkade ta reda pÄ hur man gör i c++) och flyttar in part2 koden direkt i parsningen. expandedNums innehÄller tvÄ rapporter: check pÄ första, flytta ner andra med en valignq och check pÄ den.
Den hÀr versionen av dag2 del2 kör parsning + berÀkning pÄ drygt 7ms för 1 miljon rapporter (x1000 input). 125+ miljoner rapporter * 8 per sekund Àr vÀl hyffsat snabbt iaf sÄ jag tycker nog att det Àr ett problem som lÀmpar sig bra för simd.
Nu har jag gÄtt och dragit pÄ vetskapen att jag kunde göra bÀttre ifrÄn mig pÄ pÄ SIMD-koden. Den jÀmförde samma vÀrden flera gÄnger. Jag var tvungen att pröva bara för att kunna slÀppa problemet. HÀr kommer lite ett lite optimerat exempel (rad 119). Det Àr nÀstan en halvering av körtiden jÀmfört med originalversionen. Skall vÀl erkÀnna att jag skalade upp mÀngen rapporter till en 64-multipel för att bli av med kollen pÄ om det var ett halvfullt sista block.
Nu fÄr det vara nog, nu kan jag slÀppa det hÀr