Permalänk
Inaktiv

Linux - Python3 - eller vad?

Skall köra ett Python3 program som gör matematiska väderberäkningar. Behöver en otroligt snabb lösning. Är Ubuntu eller annan Linux lösning med Python3 snabbare än t.ex. Windows 10/Python3? Datorn skall köras offline så behöver inget tjafs, av typen anti-virus, internet eller annat lull-lull som ligger och bromsar i bakgrunden. Utan rent bare-bone. Har någon ett bättre förslag? Jag är inte helt låst till Python3 utan kan nog få till beräkningsprogrammet i annat språk om det finns ett bättre förslag. Python3 är dock ganska enkelt att lära sig och har vettiga moduler.

Sedan undrar jag vad som ökar hastigheten mest? Alltså skall jag lägga pengarna på en processor med många kärnor/trådar och ett stort/snabbt ram-minne eller är grafikkortet det som ger snabbheten i beräkningarna? Jag skall villigt erkänna att jag inte vet hur Linux/Ubuntu hanterar beräkningar i Python3. Eftersom jag är old-school så tror jag att det är processorn och minnet som betyder något, men jag kanske helt enkelt tänker fel och att Python3 klarar av att hantera ett riktigt bra grafikkort automatiskt och bättre än den hanterar en CPU.

Kanske att AMD Ryzen 24 eller 32 kärnor för 15-20K är bästa vägen? Visst en 64 kärnor vore drömmen, men 45K bara för processorn blir det inte tal om.

Permalänk
Medlem

Ska du programmera själv eller köper du mjukvaran nånstans ifrån?

Har du en vettig parallelism i beräkningsalgoritmen?

Permalänk
Medlem

För att svara lite längre - det känns som om det är lite fel fråga, eller i alla fall underspecat på något vis.

Det absolut viktigaste, viktigare än programmeringsspråket, är nog algoritmen och dess egenskaper. Hur stort datamängd ska du beräkna över? Är det saker som ryms i cache eller i RAM eller måste du ned på disk i varje varv? Hur parallell kan du göra algoritmen, och hur mycket kommer en process eller en tråd att behöva interagera med resultatet av en annan tråd eller process? Svaren på detta kommer styra lite vad som är rätt hårdvara och om du kan köra med separata processer eller om du vill ha trådar som kan dela minnesutrymme.

Python i sig har ju ett klassiskt problem med "Global Interpreter Lock" som gör att det inte ensamt med sin egen trådmodell har varit det klassiska sättet att lösa problem som är "CPU-bound", i alla fall inte parallellt. Där jag har varit med har det lösts genom att ha ett Python-program som styr en massivt parallell beräkningskod skriven i C++.

Att programmera för grafikkort med sin massivt parallella modell är annorlunda än att programmera "som vanligt". Inte omöjligt, men lite annat tankesätt. Det kommer inte av sig själv i något språk.

Samtidigt finns det ju fler och fler beräkningsmoduler som är färdiga att anropa från Python, och om du kan avända någon av dem så förkortar du ju utvecklingstiden radiaklt.

Operativsystemsvalet kommer nästan sist i listan, även som saker som t.ex. hastighet på filläsning och liknande kan påverka. I de flesta fall är ju 99,9% av beräkningskoden lätt att flytta och några timmars arbetstid är ju oftast dyrare än hårdvaran i alla fall.

Och i min erfarenhet - oavsett modell så kan du enkelt göra småfixar eller misstag som gör din kod som sirap eller som tiodubblar hastigheten. I ett av de där C++-hacken jag snackade om ovan var det en utvecklare som körde en profiler på en kodsnutt av ren nyfikenhet, såg att en datastruktur inte rymdes i cachen och efter fix av det tredubblades prestandan i den viktigaste delen av koden. Eller som i GIL som jag nämnde ovan, att en process eller tråd väntar på en annan i onödan. Så underskatta inte kvaliteten på programmeraren och hennes erfarenhet.

Permalänk
Inaktiv

Det är nog mest frågan om att programmera själv. Det handlar om två linjära algoritmer som körs parallellt, som får sina värden från extern givare, och som sedan skall kontrollera mot värden i en fastställd lista. Ingångsvärdena ändrar ju sig med vädret så att säga. Men jag skall villigt erkänna att jag inte har någon 100% plan. Jag har ett behov som måste tillgodoses.
Det kanske räcker med den enklaste CPU'n med stort cache och hög klockfrekvens och mycket ram?

Permalänk
Inaktiv

Stort tack för ditt uttömmande svar. Fått lite mer kött på benen och har lite till att fundera på.

Permalänk
Medlem

Som du beskriver det låter det som ganska lite kod som körs på varje givarvärde?

Även den billigaste Celeron-processorn idag kör ju två kärnor i över 3 GHz och kostar bara fyra hundra spänn. Det innebär att du hinner med 3 miljoner klockcykler på en millisekund. Hur ofta får du värden från givaren? Eller hur ofta ändrar sig givaren så det är vettigt att läsa ett nytt värde? Och vad ska du göra med värdet sen, skriva till disk? Även där kan du skapa egna flaskhalsar.

Mycket frekvens, cache och RAM är förvisso aldrig fel, speciellt om RAM gör att du slipper läsa saker från disk.

Jag skulle nog ändå börja med att hacka ihop en snabbversion av algoritmen i det språk du är bekväm med och köra på hårdvara du redan har och sen kolla hur lång tid det tar att köra koden och vad som tar tid. Nyckelordet är "profilering".

Några snabba länkar:

https://towardsdatascience.com/how-to-profile-your-code-in-py...
https://medium.com/better-programming/a-comprehensive-guide-t...

När du sen ser vad som tar tid och hur du förstår algoritmen kan du ju fundera över om du vill byta språk, bli mer parallell eller köpa dyrare hårdvara.

Utan att veta något om dina algoritmer är min gissning att Python oavsett miljö kanske räcker, men om det inte gör det så är C++ nästa steg om du inte hittar rätt färdigt bibliotek att använda. Och hårdvaran kommer som tredje steg i optimeringen.

Permalänk
Inaktiv

3 miljoner klockcykler på en millisekund är nog fullt tillräckligt.

Jag är mycket glad att jag ställde frågan som gnagt i flera veckor. Och jag är otroligt tacksam för dina uttömmande svar.

Tack för att du tog dig tid och förklarade. Länkarna kommer jag läsa noggrant.

Permalänk
Medlem

Tack för att det uppskattades.

Man ska inte underskatta profilering. Jag har varit med om att saker sägs gå långsamt så man behöver dyrare hårdvara, men när man börjar gräva visar det sig att det man "egentligen" gör tar en millisekund men sen tar en ogenomtänkt skrivning till debug-loggen 150 gånger längre tid eftersom den vill vara säker på att diskskrivningen gått bra och liknande.

Och ännu värre, att man börjar optimera kod som räknar ut fel resultat. Först ska koden räkna rätt, annars spelar det ingen roll om den är snabb.

Permalänk
Moderator
Forumledare

*tråd återställd*

@anon330055: Vänligen förstör inte tråden genom att radera/redigera dina inlägg.
Det är ganska oförskämt mot medlemmarna som lägger ner tid på att hjälpa dig med dina frågor

Visa signatur

Forumets regler | Har du synpunkter på hur vi modererar? Kontakta SweClockers/moderatorerna

Jag stavar som en kratta

Gillar lök på discord