Inlägg

Inlägg som Elgot har skrivit i forumet
Av Elgot
Skrivet av heretic16:

/* Prepare FFT */
DFTI_DESCRIPTOR_HANDLE descriptor;
DftiCreateDescriptor(&descriptor, DFTI_SINGLE, DFTI_COMPLEX, 1, n);
DftiSetValue(descriptor, DFTI_PLACEMENT, DFTI_INPLACE);
DftiCommitDescriptor(descriptor);

Detta kan typiskt ta lite tid, så ett tips är att spara deskriptorn och återanvända den om du behöver göra en likadan beräkning senare. (Och det gäller även i 2d-fallet)

Av Elgot
Skrivet av heretic16:

Så MKL är en solklar vinnare när det kommer till 2D. Annars så är FFTPack från Pretty Fast FFT snabbare när det kommer till 1D, jämfört med MKL.

Det gäller dock bara mindre matriser och vektorer. T.ex. 100 tusen.

Kanske finns det en statisk fördröjning i anropet? Om du tänker göra många snarlika beräkningar efter varndra kan du minska antalet anrop genom att utföra många beräkningar åt gången.

Av Elgot
Skrivet av sweborn:

Det är ju inte hur kompakt koden är utan vilka instruktioner den resulterar i som spelar roll.

Om man försöker göra smarta saker finns det också risk för att kompilatorn inte vågar göra ännu bättre optimeringar.

Av Elgot
Skrivet av heretic16:

Så om jag ska skriva om cv::mat som är matris för OpenCV. Då kan jag göra en struktur istället med typedefinition cv_mat?

Jag väljer att skriva om OpenCV C++ kod för att jag vill inte uppfinna hjulet på nytt.

Ja, troligen. Såhär skulle man till exempel kunna använda en std::string från c:

//string_wrapper.h #ifndef STRING_WRAPPER_H #define STRING_WRAPPER_H #ifdef __cplusplus extern "C" { #endif struct string_wrapper; struct string_wrapper* new_string(const char* str); const char* get_string(struct string_wrapper* sw); int get_size(struct string_wrapper* sw); void free_wrapper(struct string_wrapper* sw); #ifdef __cplusplus } #endif #endif

//string_wrapper.cpp #include "string_wrapper.h" #include <string> struct string_wrapper { std::string str; }; string_wrapper* new_string(const char* str) { string_wrapper* sw = new string_wrapper(); sw->str = str; return sw; } const char* get_string(string_wrapper* sw) { return sw->str.c_str(); } int get_size(string_wrapper* sw) { return sw->str.size(); } void free_wrapper(string_wrapper* sw) { delete sw; }

#include <stdio.h> #include "string_wrapper.h" //main.c int main() { struct string_wrapper* sw = new_string("Hello world"); printf("%s: %d\n", get_string(sw), get_size(sw)); free_wrapper(sw); return 0; }

Av Elgot

En vanlig lösning är väl att skriva ett litet mellanlager i c++ som exponerar ett (troligen förenklat) c-gränssnitt som den andra applikationen kan använda?

Av Elgot
Skrivet av SwedenVirre:

Det jag har märkt mycket på jobbet är att Windows 11 är mer resurs krävande än Windows 10, sure finns där fall där 11an faktiskt är bättre med bättre optimering för BIG.little arkitektur.

Mycket är kanske bara dåligt testad mjukvara? De har ju haft problem med minnesläckor i utforskaren och liknade.

Skrivet av jnsson:

Är samma nyckelsystem till W10 som till W11 så det bör inte vara någon skillnad alls

Windows 7-nycklar fungerar väl också?

Av Elgot
Skrivet av mar3ld:

Jag håller inte med dig.

Vet du, varje gång jag sätter mig bakom ratten är jag villig att ta den risken du nämner, dvs att jag råkar köra över ett enskilt barn eller t o m en hel skolklass. För att däremot minimera risken för en sådan olycka ser jag mig omkring och kör så säkert jag kan.

Och även om risken trots min försiktighet kvarstår är jag ändå inte beredd att ändra mig på den punkten, rent generellt. Jag tycker nämligen att: Bara för att det händer olyckor emellanåt så ska man inte nödvändigtvis förbjuda den involverade prylen eller aktiviteten. Det handlar för mig om att shit faktiskt happens — men världen går inte nödvändigtvis under för det.

Nej, men resten av samhället kommer förmodligen inte vara lika förstående. Det är väl ingen större skillnad mot hur hastighetsgränser fungerar idag?

Av Elgot
Skrivet av Parmenides:

Att köra bil på landsväg är en frihetsupplevelse man kan unna sig som svensson. Förstår inte myrstacksmentaliteten som vill ta ifrån oss den möjligheten.

Problemet uppstår väl den dag när mänskliga förare är betydligt farligare än artificiella? Det kommer se illa ut när ett barn har blivit påkört av någon som har slagit av autopiloten för att det är kul att styra själv…

Av Elgot
Skrivet av Timmy Fox:

Jovisst, men det tillför ju ännu fler steg att öppna upp ett till fönster som sedan måste peka några steg upp i hierarkin (dit man vill flytta filen). Så IMO är det enklare och snabbare att bara klippa och klistra.

Ja, och det är väl den metoden så gott som alla använder också? Jag menar bara att om man av någon anledning vill använda enbart musen kan man fortfarande göra på det traditionella sättet (som i alla andra grafiska filhanterare).

Av Elgot
Skrivet av Timmy Fox:

...Helt ärligt har jag faktiskt känt av detta nu vid ett flertal tillfällen över de senaste dagarna.

Har man en fil eller något in en mapp som man vill flytta högre upp i hierarkin så känns det ändå ganska naturligt att använda dra-och-släpp funktionen såhär.

Typ om jag har en mappstruktur:
- Filer
-- Projekt1
--- Projektfil1

Om jag nu av någon anledning vill flytta Projektfil1 till huvudmappen (Filer) så har jag två grafiska alternativ:

  1. Klipp filen (CTRL+X)

  2. Flytta mig till huvudmappen

  3. Klistra filen (CTRL+V)

Eller:

  1. Dra Projektfil1 till där det står "Filer" i aktivitetsfältet och släpp musknappen

...Och nu funkar alltså inte det sistnämnda alternativet, så kopiera och klistra är i princip nu det huvudsakliga alternativet att köra på, om man vill göra det i Utforskaren.

Ett annat alternativ är väl att dra mellan två olika fönster?
Dock är det väl inte omöjligt att den här funktionaliteten faktiskt återkommer i framtiden (om någon efterfrågar den)? Troligen handlar det mest om att man inte har tid (eller lust) att implementera precis alla finesser när man skriver om applikationer.

Av Elgot

Man kan väl ha viss förståelse för att många vill använda de nya ramverken så fort som möjligt, men man skulle ju önska att de mest fundamentala delarna fick vara ifred tills alternativen åtminstone var ordentligt genomtestade. Och skall man offra funktionalitet och prestanda vill man ju helst ha något i utbyte.

Av Elgot
Skrivet av Fissure:

Beror på hur långt man ser på saker o ting. Visst folk betalar, men överpris är fortfarande överpris. Jag tänker själv att mycket hänger samman och och i slutändan så resulterar överpriser på varor (inte bara Apples) att klyftorna i världen ökar och mer kapital slutar hos de redan överdrivet rika. Vet jag låter som en kommunist här men lite lagom tänker jag borde vara bäst.

Det skulle man kanske kunna hävda om skoexemplet ovan (det verkar ju ha handlat om några dussin influencers som "gick på det"), men det är ju ändå väldigt många som har en telefon från den övre prisklassen (inte minst ungdomar). Det verkar finnas mycket pengar att lägga på telefoner, så det är klart att tillverkarna kommer försöka möta behovet.

Av Elgot
Skrivet av Mizccc:

Bara en riktigt inbiten fanboy försvarar detta slags beteende. Vad har Apple själva att säga till sitt försvar? Produkterna är ju redan otroligt överprisade.

Har du sett hur bra de säljer? Visst är priset högt, men kanske är det inte fel?

Av Elgot

Finns det siffror på hur många som pillar med datorer numera? Är det verkligen så hett bland dagens ungdom ens före dessa tjänster?

Av Elgot
Skrivet av heretic16:

Jag har redan MKL. MKL fungerar bra...men den är för C99 om man vill ha det i komplex format. Men den har stöd för ANSI C om man klipper och klistrar lite med 2 extra element i en array.

Du behöver dock som sagt inte ändra i koden; fortsätt att köra fftw-arrayer (som är ansi-c) och länka bara till mkl istället för fftw.

Skrivet av heretic16:

Men jag tyckte att MKL var inge snabb. Den var seg.

I det här fallet verkar faktiskt mkl lite snabbare. 190 ms mot 250 ms för fftw.

Det här programmet bör du kunna bygga direkt och länka till mkl eller fftw:

//#include <fftw3.h> typedef float fftwf_complex[2]; struct fftwf_plan_s; typedef struct fftwf_plan_s* fftwf_plan; int __cdecl fftwf_int_threads(); void __cdecl fftwf_plan_with_nthreads(int nthreads); int __cdecl fftwf_import_wisdom_from_filename(const char* filename); int __cdecl fftwf_export_wisdom_to_filename(const char* filename); fftwf_complex* fftwf_alloc_complex(size_t n); fftwf_plan __cdecl fftwf_plan_dft_2d(int n0, int n1, fftwf_complex* in, fftwf_complex* out, int sign, unsigned flags); void __cdecl fftwf_destroy_plan(fftwf_plan plan); void __cdecl fftwf_free(void* p); void __cdecl fftwf_cleanup_threads(); #define FFTW_FORWARD (-1) #define FFTW_BACKWARD (+1) #define FFTW_MEASURE (0U) #define FFTW_DESTROY_INPUT (1U << 0) #define FFTW_UNALIGNED (1U << 1) #define FFTW_CONSERVE_MEMORY (1U << 2) #define FFTW_EXHAUSTIVE (1U << 3) /* NO_EXHAUSTIVE is default */ #define FFTW_PRESERVE_INPUT (1U << 4) /* cancels FFTW_DESTROY_INPUT */ #define FFTW_PATIENT (1U << 5) /* IMPATIENT is default */ #define FFTW_ESTIMATE (1U << 6) #define FFTW_WISDOM_ONLY (1U << 21) #include <stdlib.h> #include <stdio.h> #include <time.h> const int fftSize = 5000; fftwf_complex* fftInput; fftwf_complex* fftOutput; fftwf_plan fftPlan; int main(int argc, char* argv[]) { // fftwf_init_threads(); // fftwf_plan_with_nthreads(4); fftwf_import_wisdom_from_filename("wisdom.dat"); fftInput = fftwf_alloc_complex(fftSize * fftSize); fftOutput = fftwf_alloc_complex(fftSize * fftSize); fftPlan = fftwf_plan_dft_2d(fftSize, fftSize, fftInput, fftOutput, FFTW_FORWARD, FFTW_MEASURE | FFTW_PRESERVE_INPUT); fftwf_export_wisdom_to_filename("wisdom.dat"); for (int i = 0; i < fftSize * fftSize; ++i) { fftInput[i][0] = rand() % 1000000; fftInput[i][1] = rand() % 1000000; } clock_t start, end; double cpu_time_used; start = clock(); const int N = 10; for (int q = 0; q < N; ++q) fftwf_execute(fftPlan); end = clock(); cpu_time_used = ((double)(end - start)) / CLOCKS_PER_SEC; printf("CPU Time used: %f seconds\n", cpu_time_used/N); fftwf_destroy_plan(fftPlan); fftwf_free(fftInput); fftwf_free(fftOutput); // fftwf_cleanup_threads(); }

Om du länkar till mkl behöver du inte befatta dig med fftw alls.

Av Elgot
Skrivet av heretic16:

Problemet är att jag vet inte vilka filer jag ska ha. FFTW är inte pedagogiskt skrivet direkt.

Man behöver inte veta så mycket. Du behöver inkludera fftw3f.h och sedan länka till fftw3f.lib (windows) eller libfftw3f (linux) eller mkl. Om biblioten inte finns i systemet kan man bygga dem genom att köra cmake.

Skrivet av heretic16:

Sedan så kräver FFTW3 att man ska vara licensierad mot MIT om det ska användas i kommersiella produkter.

Ja, licenser kan ju däremot vara ett problem men man borde komma runt det om man använder mkl.

Av Elgot
Skrivet av heretic16:

Det går självklart snabbare I Octave

>> tic; fft2(randn(5000,5000)); toc Elapsed time is 0.671597 seconds. >>

Nu räknar du också med dubbel precision.
>> m=single(randn(5000,5000)); tic; fft2(m); toc
borde vara ytterligare lite snabbare.

Skrivet av heretic16:

Så 1.7 sekunder är inte illa, med tanke på att det är bara en enkel C fil Jag har försökt optimera detta så bra som möjligt.

Antalet filer är ju dock inget man normalt bryr sig om. Lägg dem i en egen mapp, bygg och länka. Eller använd en färdigbyggd version.
Man skulle säkert kunna refaktorera fftw till enstaka filer också, men det vanliga är väl snarare att gå åt andra hållet för ökad översiktlighet.

Av Elgot
Skrivet av heretic16:

Testa och kör dessa exempel: https://easyupload.io/b7kr10

Kolla vad du får för tid vid 5000*5000 matris.
Det tog 3.15 sekunder för mig.

Kom alla filer med (finns det en main till exempel)?

Hur lång tid tar det för dig i matlab?
En slumpad 5000x5000-matris tar 0,4 sekunder i octave på den dator jag sitter vid just nu och mitt program är något snabbare (0,35 s, och 0,25 s med fyra trådar).

Edit:
På en dator där octave tar 0,13 sekunder tar din fft2 1,7 sekunder.

Av Elgot
Skrivet av heretic16:

Jo, fast FFTW använder säkert trådar.

Det kan den göra om man ber den, men det förklarar inte skillnaden (i just det här fallet verkar det inte göra så stor skillnad heller). Pffft har ju också stöd för simd, så det borde inte vara det heller.

Skrivet av heretic16:

FFTW är säkert jättebra, men det verkar vara mycket filer. fftpack.c/h från PFFFT är bara två filer och är riktigt snabbt. Så jag känner mig nöjd.

Tror jag inte kan få det snabbare. FFTW3 sägs inte vara den snabbaste heller. Tror mycket handlar om vilken hårdvara och kompilator man använder. Jag kör MSVC.

Fler filer är det förstås, men är det verkligen så mycket att bry sig om? Om man länkar till mkl (eller om fftw redan finns i systemet) behöver man heller inte mer än h-filen.
Jag har testat gcc (i windows och linux) och msvc på hyfsat modern x86_64, och det verkar inte vara så stor skillnad.

Av Elgot
Skrivet av heretic16:

Med FFTpack 5.1 så tog det 5.3 sekunder att göra FFT 2D på en 5000*5000 matris.

Dessutom gav fftpack.h och fftpack.c filen från Pretty Fast FFT 100% exakt samma resultat som Matlab.
Notera att detta är utan någon optimeringsflagga eller liknande. Bara ren ANSI C kod som är plattformsoberoende.

Det var trixigt att få till rffti -> rfftf -> cffti -> cfftf då det inte finns någon manual eller ens folk som verkar använda det, trots att FFTpack är snabbt om man väljer den från Pretty Fast FFT.

FFTW verkar väl ändå vara närmare 10 gånger snabbare (och plattformsoberoende ansi-c), och folk i allmänhet bryr sig kanske inte så mycket om hur många filer som ingår? PFFFT verkar ju också förespråka att man bygger det som ett bibliotek.