Hur kan jag få tag på prestandaversionen av Nucleo?

[bearing]

JAg googlade på:
stm32 cortex m4 instruction set summary

FAnn detta:
http://infocenter.arm.com/help/index.js ... DIGAC.html

Ser inte några FPU instruktioner vid en snabb titt, så FPUn har kanske en egen spec, eller så missade jag dom instruktionerna.

[DanielM]

Jag tänker bara ha denna sak för mig själv. Men jag förstår vad du menar. Man ska inte använda för stor processor om behovet inte finns.

Edit:

Kod: Markera allt

100111 = 39 = a
1001 = 9 = b

a/b = 39/9 = 4.3333333333
a/b = 100111/1001 = 100.01010101

Undra om en FPU är snabbare än om man dividerar binärt?

För att få resultatet 100.01010101 (8 bimaler) måste du först skifta a 8 steg vänster innan divisionen, annars trunkeras de värdesiffror som sedan blir bimaler i resultatet, d.v.s resultatet skulle bara bli 4.
a/b = (100111 << 8 /1001) >> 8 = 10011100000000/1001 >> 8 = 10001010101 >> 8 = 100.01010101 fixed point= 4,33 dec

Redan här ser jag att jag kommer få skriva om mitt bibliotek om jag ska konvertera allt tilll binärt.
Målet med mitt bibliotek är att den både ska kunna användas för numerisk analys i C.

[DanielM]

JAg googlade på:
stm32 cortex m4 instruction set summary

FAnn detta:
http://infocenter.arm.com/help/index.js ... DIGAC.html

Ser inte några FPU instruktioner vid en snabb titt, så FPUn har kanske en egen spec, eller så missade jag dom instruktionerna.

Jag tror att om jag skulle utveckla egna funktioner, så kommer dom garanterat vara sämre än om jag använder FPU:n.

[bearing]

Det kan du inte garantera utan att ta fram all info som behövs för jämförelsen.

Heltalsdivision, uint32 / uint32, som använder instruktionen UDIV, tar mellan 2 och 12 cykler enligt min länk. FPU-specen orkar jag inte leta fram nu, det får du göra själv, men bli inte förvånad om flyttalsdivision (float / float) tar betydligt längre tid. Beror på hur avancerad och "dyr" FPUn är. På vissa FPU tar en DIV 200 cykler, medan på andra knappt mer än en heltalsdivision.

Men med tanke på att du ska sampla med runt 1 Hz tror jag inte att detta har någon större betydelse, såvida du inte gör väldigt avancerade beräkningar. Det verkar du ju dock göra. Så det kan vara bra att göra en ordentlig jämförelse mot heltalsalgoritm ifall flyttalsalgoritmens exekveringstid misstänks närma sig samplingstiden. Vilket skulle kunna vara fallet enligt dina tidigare inlägg. Oklart dock vad du gjorde när du presenterade de tiderna, så detta får du bedömma själv.

[svanted]

Jag är däremot lite utav en arbetsledare i mitt arbetsliv där jag ofta ställer frågan "Tid & Kostnad"

tar du betalt för ALL tid du lägger ner för att lösa problemen med dina floatproblem?
du tillbringar 100tals timmar på ett forum, vem fakturerar du det?

kan det vara så att du på din fritid skriver de libbar du så enkelt och billigt kan använda i jobbet?

[Janson1]

Det här med flyttal kontra heltal och att göra om allt till heltal tror jag t.o.m. jag börjar förstå lite av, inte mycket men lite...
Jag "programmerar" bara i 8 bitars arduino Atmega328 och jag använder i dag float när jag behöver decimaltal men har blivit lite varnad för att det kan ta för många cykler/för lång tid att räkna ut. Jag har ett tidskritiskt program men än så länge räcker tiden till. Min minsta öronmärkta uträkningstid är 200 uS. Jag kan läsa om att det i ditt fall Daniel så räcker det med en uträkning per sekund så ur det tidsperspektivet så borde vilken som helst processor klara detta oavsett vad som hittas på? (det skall vara användbart också) Men som sagt, jag kan egentligen inget om programmering mer än väldigt lite inom Arduino så mitt inlägg kanske är irrelevant?

[sodjan]

> så räcker det med en uträkning per sekund...

Nu så är det ju inte *en enda* operation som det gäller. Jag har inte fattat
allt, men det är ju något slags beräkningsloop som dessutom inte är deterministisk
(d.v.s. att antalet operationen kan variera efter invärdena, som jag fattar), så
det är inte helt lätt att bedöma det hela.

Som jag ser det så handlar det mer om de valda algoritmerna än om hur man
representerar de ingående värdena. Min känsla är att det bara har valts det mest
"flashiga" som gick att hitta och sen att försöka klämma in det i processorn. Sen
om det är det mest optimala eller "bästa" för att lösa uppgiften är en annan sak...

Och att diskussionen på senaste sidorna har spårat in på float vs. integer är, tja...

[Rick81]

Det finns ingen anledning att skriva om din kod till FPU så länge du inte måste köra koden på en billigare processor.

Ändra ditt lib där du inte vet vilka decimaler som krävs i beräkningarna för göra om till fixed point när du ändå har FPU kommer inte vara värt besväret

[DanielM]

Det kan du inte garantera utan att ta fram all info som behövs för jämförelsen.

Heltalsdivision, uint32 / uint32, som använder instruktionen UDIV, tar mellan 2 och 12 cykler enligt min länk. FPU-specen orkar jag inte leta fram nu, det får du göra själv, men bli inte förvånad om flyttalsdivision (float / float) tar betydligt längre tid. Beror på hur avancerad och "dyr" FPUn är. På vissa FPU tar en DIV 200 cykler, medan på andra knappt mer än en heltalsdivision.

Men med tanke på att du ska sampla med runt 1 Hz tror jag inte att detta har någon större betydelse, såvida du inte gör väldigt avancerade beräkningar. Det verkar du ju dock göra. Så det kan vara bra att göra en ordentlig jämförelse mot heltalsalgoritm ifall flyttalsalgoritmens exekveringstid misstänks närma sig samplingstiden. Vilket skulle kunna vara fallet enligt dina tidigare inlägg. Oklart dock vad du gjorde när du presenterade de tiderna, så detta får du bedömma själv.

Simplex, Recursive Least Squares kommer jag använda.

Jag är däremot lite utav en arbetsledare i mitt arbetsliv där jag ofta ställer frågan "Tid & Kostnad"

tar du betalt för ALL tid du lägger ner för att lösa problemen med dina floatproblem?
du tillbringar 100tals timmar på ett forum, vem fakturerar du det?

kan det vara så att du på din fritid skriver de libbar du så enkelt och billigt kan använda i jobbet?

Detta är ett hobbyprojekt bara. Hade jag gjort en affärsidé utav det hela så hade jag inte sittit här eller ens funderat på om jag ska konvertera om float till uint.

Nej. Detta har inget med jobb att göra.

Det finns ingen anledning att skriva om din kod till FPU så länge du inte måste köra koden på en billigare processor.

Ändra ditt lib där du inte vet vilka decimaler som krävs i beräkningarna för göra om till fixed point när du ändå har FPU kommer inte vara värt besväret

Grejen med mitt bibliotek är att man först gör numeriska beräkningar i det på en PC och sedan flyttar över det till en processor.

Jag köpte mitt Nucleo kort för 200 kr.

[Rick81]

Simplex, Recursive Least Squares kommer jag använda.

Du är med på att detta inte är processor instruktioner? Dvs ingen kan svara på hur mycket snabbare uint mot float blir. Enda sättet är att benchmarka tex den som tar längst tid, en version med uint och en version med float och jämföra exekveringstid.

Grejen med mitt bibliotek är att man först gör numeriska beräkningar i det på en PC och sedan flyttar över det till en processor.

Vad har det med uint/float att göra?

[Mr Andersson]

Jag tycker hela diskussionen är konstig.
TS säger att hans lösning fungerar och är nog snabb. Och den ska inte massproduceras.
Då finns det väl ingen anledning att börja bråka om alternativa lösningar för att få ner enhetskostnaden?

- Din lösning är för dyr för att massproduceras.
- Ja men jag ska bara ha den själv.
- Den är ändå för dyr för att massproduceras.

På en modern* ARM så har flyttalsoperationer samma prestanda som heltal, givet att datavolymen är nog stor.
Den enda anledningen jag kan se till att välja bort flyttal är om upplösningen inte räcker till, men TS har ju skrivit tidigare att det redan fungerar.

*) Har cortex-m NEON?

[bearing]

Det var ju han själv som tog upp att han ville använda fixed point. Antagligen på grund av den långa diskussionen med TomasL, som jag inte orkade läsa. Jag skrev att jag misstänkte att det var bättre att köra vidare med FPU, baserat på erfarenhet från hans tidigare trådar. Sen när han skrev att hans kod "garanterat" skulle gå snabbare med FPU än ifall han implementerade fixed point själv, då påpekade jag bara lite lätt att han inte har tillräckligt med info för att "garantera". Resten av inläggen är väl mest bara mer påpekanden i samma linje, medans folk väntar att trådstartaren ska komma med mer info.

Problemet i tråden är som tidigare, att han inte gör tillräckligt själv, utan har en massa ideer och diskuterar en massa, men det finns inte någon större substans i diskussionerna, då det mesta beror på hans system. Ett system som han ändrar hela tiden, och inte utvärderar tillräckligt själv. Så länge han inte ger oss rikligt med info kan vi ju bara ge generella råd. Han tolkar ofta de generella råden som specifika för hans lösning, och sätter igång och ska ändra sin lösning, när det förmodligen inte behövs.

Han verkar så rädd att misslyckas. Så tolkar jag det iaf. Han vill komma fram till den "rätta" lösningen. Att allt är genomtänkt, att det inte kommer några obehagliga överraskning på vägen, o.s.v. Men han har inte tillräckligt med erfarenhet för detta. Och tror att vi ska kunna berätta hur han ska göra. Men presenterar alltså inte tillräckligt med info för att vi ska kunna göra det.

[bearing]

Simplex, Recursive Least Squares kommer jag använda.

Här är FPUns instruktionsuppsättning:
http://infocenter.arm.com/help/index.js ... JADED.html

Snabb division, och har en instruktion för roten ur float. Finns ingen heltalsinstruktion för roten ur, så om du behöver beräkna kvadratrötter ofta kommer programmet antagligen gå snabbare ifall du använder floats och inte heltal.

[DanielM]

Här är FPUns instruktionsuppsättning:
http://infocenter.arm.com/help/index.js ... JADED.html

Snabb division, och har en instruktion för roten ur float. Finns ingen heltalsinstruktion för roten ur, så om du behöver beräkna kvadratrötter ofta kommer programmet antagligen gå snabbare ifall du använder floats och inte heltal.

Tackar. Som jag misstänkte. Lika bra att utnyttja FPU:n istället för att köra på uint.

Du är med på att detta inte är processor instruktioner? Dvs ingen kan svara på hur mycket snabbare uint mot float blir. Enda sättet är att benchmarka tex den som tar längst tid, en version med uint och en version med float och jämföra exekveringstid.

Vad har det med uint/float att göra?

Det har mycket med uint och float att göra. Säger jag så, så är det så.
Jag gör testsimuleringar i C för att kolla om beräkningarna stämmer. Stämmer dom, så flyttar jag helt enkelt över koden till min kontroller.

Jag tycker hela diskussionen är konstig.
TS säger att hans lösning fungerar och är nog snabb. Och den ska inte massproduceras.
Då finns det väl ingen anledning att börja bråka om alternativa lösningar för att få ner enhetskostnaden?

- Din lösning är för dyr för att massproduceras.
- Ja men jag ska bara ha den själv.
- Den är ändå för dyr för att massproduceras.

På en modern* ARM så har flyttalsoperationer samma prestanda som heltal, givet att datavolymen är nog stor.
Den enda anledningen jag kan se till att välja bort flyttal är om upplösningen inte räcker till, men TS har ju skrivit tidigare att det redan fungerar.

*) Har cortex-m NEON?

Jag frågade TomasL om det är lätt att göra matematiska operationer via uint och frågade om han kunde visa. Som vanligt så fick jag ett käftigt idiotförklarande svar tillbaka och då uppfattade jag att det var bara vanlig matematik +, -, /, * och då behöver jag bara byta ut float mot uint32.

Det var ju han själv som tog upp att han ville använda fixed point. Antagligen på grund av den långa diskussionen med TomasL, som jag inte orkade läsa. Jag skrev att jag misstänkte att det var bättre att köra vidare med FPU, baserat på erfarenhet från hans tidigare trådar. Sen när han skrev att hans kod "garanterat" skulle gå snabbare med FPU än ifall han implementerade fixed point själv, då påpekade jag bara lite lätt att han inte har tillräckligt med info för att "garantera". Resten av inläggen är väl mest bara mer påpekanden i samma linje, medans folk väntar att trådstartaren ska komma med mer info.

Problemet i tråden är som tidigare, att han inte gör tillräckligt själv, utan har en massa ideer och diskuterar en massa, men det finns inte någon större substans i diskussionerna, då det mesta beror på hans system. Ett system som han ändrar hela tiden, och inte utvärderar tillräckligt själv. Så länge han inte ger oss rikligt med info kan vi ju bara ge generella råd. Han tolkar ofta de generella råden som specifika för hans lösning, och sätter igång och ska ändra sin lösning, när det förmodligen inte behövs.

Han verkar så rädd att misslyckas. Så tolkar jag det iaf. Han vill komma fram till den "rätta" lösningen. Att allt är genomtänkt, att det inte kommer några obehagliga överraskning på vägen, o.s.v. Men han har inte tillräckligt med erfarenhet för detta. Och tror att vi ska kunna berätta hur han ska göra. Men presenterar alltså inte tillräckligt med info för att vi ska kunna göra det.

Du vet väldigt lite ska du veta.

Jag är inte rädd att misslyckas. Men jag lyssnar på andras förslag. Sedan är det upp till mig att värdera behovet.

Jag har även testat mitt bibliotek för på min STM32 och den visar exakt samma siffror som MATLAB.
Det är machine learning jag håller på med. Ingen verkar dock vara intresserad utav det biblioteket.

[bearing]

Jag vet inte i vilket sammanhang du menar att jag inte vet mycket, men det bekymrar mig inte så mycket vad du tycker. Men jag kan konstatera att du utan konkurrens är den mest ineffektive forummedlem vi haft sedan jag blev medlem. Då syftar jag på hur effektivt du utnyttjar forumets resurser. Detta har jag iofs varit inne på i andra av de otaliga trådar du startat om ditt projekt. Men eftersom att det är så plågsamt att bevittna kunde jag inte hindra mig att ta upp det igen.