Gå til innhold

Anbefalte innlegg

Videoannonse
Annonse

Et lite skudd i mørke her.... du har aldri programmert i C før, har du vel? :green:

I og med at du linker til "Bare Python er Python" i signaturen din, så antar jeg du først og fremst er python-programmerer?

 

Vel, jeg er ikke særlig dreven på Python, men det har kanskje noe dynamisk kompilering elns?

I C så er det statisk kompilering. Du må kompilere før du kjører programmet.

Det vil si at når du lager en funksjon som tar et random input så kan den ikke forutse hva du vil gi som input

Endret av Drogin
Lenke til kommentar
Gjest Slettet+9871234

Jo.

 

Endog i Fortran, hvor dimensjon av todimensjonale arrays er noe herk. Hva er det du vil frem til? Dinglende pekere eller ...

 

Har også gått igjennom noen av disse

 

http://users.powerne...ndr2/index.html

 

oppgavene.

 

Mer presist disse:

 

http://users.powernet.co.uk/eton/kandr2/krx5.html

 

Det er lenge siden.

Endret av Slettet+9871234
Lenke til kommentar

Drogin, jeg skal forsøke å skrive den algoritmen du skrev om tidligere, men jeg vil benytte SSE, og det kan du også gjøre, jo flere execution units vi benytter jo bedre får vi testet hvor god kompilatoren din er, så derfor vil jeg ha med SSE også. Skriv du også den samme algoritmen, så tester vi resultater etter hvert.

 

Men jeg vil skrive for windows, jeg har ikke linux her. Vi tester på min maskin, du sender meg ditt program så tester jeg mitt og ditt samtidig. Husk å time koden nøyaktig og outputte resultatet, samt fortell meg hvor mange elementer du bruker i arrayet ditt, om du fyller arrayet ditt med random tall, så må du lage programmet slik at den printer ut timingen flere ganger og ikke bare en gang, for det kan være at selve tallene kan ha en unik effekt på timingen, derfor må vi kjøre timingen mange ganger etter hverandre, kanskje 10 tester etter hverandre.

Endret av LonelyMan
Lenke til kommentar

Drogin, jeg skal forsøke å skrive den algoritmen du skrev om tidligere, men jeg vil benytte SSE, og det kan du også gjøre, jo flere execution units vi benytter jo bedre får vi testet hvor god kompilatoren din er, så derfor vil jeg ha med SSE også. Skriv du også den samme algoritmen, så tester vi resultater etter hvert.

 

Men jeg vil skrive for windows, jeg har ikke linux her. Vi tester på min maskin, du sender meg ditt program så tester jeg mitt og ditt samtidig. Husk å time koden nøyaktig og outputte resultatet, samt fortell meg hvor mange elementer du bruker i arrayet ditt, om du fyller arrayet ditt med random tall, så må du lage programmet slik at den printer ut timingen flere ganger og ikke bare en gang, for det kan være at selve tallene kan ha en unik effekt på timingen, derfor må vi kjøre timingen mange ganger etter hverandre, kanskje 10 tester etter hverandre.

Kan godt lage det på windows.

 

Men å bruke SSE/SIMD blir litt feil, for denne testen.

Hvis man skal begynne å dra inn parallellisering, kan man begynne å snakke om å bruke f.eks CUDA for å kjøre det på skjermkortet osv, eller lage flere threads etc.

 

SSE/SIMD, skjermkort og slik paralellisering er ikke selvsagt å bruke overalt i programmet, og er typisk noe en C/C++ programmerer vi legge inn selv med libs, eller intrinsics. CUDA har en egen C-like syntax som kan brukes. Det hele blir litt for søkt å dra inn i sjekken, så jeg foreslår at vi ikke bruker parlellisering.

Endret av Drogin
Lenke til kommentar
Gjest Slettet+9871234

Nei, jeg mener, når den kompilerer funksjonen så har den jo ikke peiling på hva som vil ligge på stacken når funksjonen blir kalt i runtime. Det kan være hva som helst. Derfor kan ikke kompilatoren teste eller finne ut hva "size" er.

 

Jeg skrev ovenfor om at VLISC prosessoren som jeg leste om i 1980 / 1990 årene gjettet på neste skritt. Så lenge man er i løkken gjetter altså prosessoren riktig. Tror du ikke den prosessoren hadde en løsning når den gjettet feil, dvs kom til enden av løkken?

 

Noe tilsvarende ser jeg for meg at en god optimaliserende kompilator gjør. Dette er selvsagt mer intuisjon enn eksakt kunnskap, da jeg ikke har tid til å teste den teorien. Det har muligens andre.

 

Derfor mente jeg at du kunne funnet bedre eksempler. Menneskets hjerne er som jeg skriver ovenfor overlegen når det gjelder å finne mønstre. Det er spesielt der en god assembler programmerer vil slå en kompilator. På fraktaler viser jeg tidligere i denne tråden til en artikkel hvor samme program i assembly kjører 100 ganger raskere enn i C. Det er en gammel artikkel, men jeg tviler på at dagens kompilatorer er så gode at de slår en assembly programmerer som for eksempel Peter Norton.

Lenke til kommentar
Gjest Slettet+9871234

Dersom kalleren bruker en konstant verdi for size (og kaller og funksjon er i samme scope) er det jo mulig.

 

Noe ala det jeg skrev om i C++ midt på 90 tallet:

 

A matrix class that illustrates the use of templates etc.

 

An ARR3D class implemented as a pointer to a pointer pointer

 

Ytterligere kommentert her (post nummer #1512 og senere):

 

https://www.diskusjon.no/index.php?showtopic=800754&view=findpost&p=18465704

Lenke til kommentar

Drogin, jeg skal forsøke å skrive den algoritmen du skrev om tidligere, men jeg vil benytte SSE, og det kan du også gjøre, jo flere execution units vi benytter jo bedre får vi testet hvor god kompilatoren din er, så derfor vil jeg ha med SSE også. Skriv du også den samme algoritmen, så tester vi resultater etter hvert.

 

Men jeg vil skrive for windows, jeg har ikke linux her. Vi tester på min maskin, du sender meg ditt program så tester jeg mitt og ditt samtidig. Husk å time koden nøyaktig og outputte resultatet, samt fortell meg hvor mange elementer du bruker i arrayet ditt, om du fyller arrayet ditt med random tall, så må du lage programmet slik at den printer ut timingen flere ganger og ikke bare en gang, for det kan være at selve tallene kan ha en unik effekt på timingen, derfor må vi kjøre timingen mange ganger etter hverandre, kanskje 10 tester etter hverandre.

Kan godt lage det på windows.

 

Men å bruke SSE/SIMD blir litt feil, for denne testen.

Hvis man skal begynne å dra inn parallellisering, kan man begynne å snakke om å bruke f.eks CUDA for å kjøre det på skjermkortet osv, eller lage flere threads etc.

 

SSE/SIMD, skjermkort og slik paralellisering er ikke selvsagt å bruke overalt i programmet, og er typisk noe en C/C++ programmerer vi legge inn selv med libs, eller intrinsics. CUDA har en egen C-like syntax som kan brukes. Det hele blir litt for søkt å dra inn i sjekken, så jeg foreslår at vi ikke bruker parlellisering.

 

Du må bruke paralellisering uansett hva du gjør med den algoritmen, så det spiller ingen rolle. SSE er ekstremt vanlig i alle programmer. Skjermkortet mitt støtter CUDA men nå har jeg aldri koded CUDA og det er iallefall noe som er skjeldent brukt i vanlige programmer, så jeg tror vi dropper CUDA :hm:

Lenke til kommentar

ah, med "paralellt" så mente jeg bare å gå igjennom begge arrayene i samme loop(i og med at de er like lange).

 

Men vi kan jo egentlig ta en enklere oppgave.

Implementer din egen int strlen(char *str), så gjør jeg det samme.

 

Input kan være en hvilken som helst vanlig string, la oss si den må ha 50 000 000 tegn.

Lenke til kommentar
Gjest Slettet+9871234

Paralellisering er vel et typisk problem der en god kompilator skriver kompakt og effektiv assembly kode. Jeg vil anta at mindre predikerbare problemer vil skille bedre.

 

Lengde en ganske uvesentlig etter mitt min mening, når veien gjennom strengen, matrisen etc. er kjent.

 

Er det mulig å finne noen eksempler der den menneskelige hjerne straks ser mønstre, mens en kompilator vil ha problemer med å se slike mønstre.

 

Analogi:

 

Et menneske greier umiddeltbart å gjenkjenne et ansikt blant 10 tusener i en storby. Et menneske greier umiddelbart å skjelne en fugl fra et fly, fra en sky, fra et blad, fra et papir som flyr i luften.

Endret av Slettet+9871234
Lenke til kommentar

La oss heller lage en rutine for å rotere strenger (rot13) så slipper jeg å skrive alt på nytt, der har jeg allerede skrevet en funksjon. Så kan jeg se om jeg kan optimalisere den videre. Skriv du også en rot13 funksjon som roterer, la oss si 100 MB med strengdata. :) Bruk den tiden du trenger.

 

Gi meg så resultatet hvor raskt du klarer å rotere 100 MB. Rot13 krever ingen andre execution units, så det er perfekt.

Endret av LonelyMan
Lenke til kommentar
Gjest Slettet+9871234

Spennende nok, men skiller det nok på den ASM koden et menneske skriver og den en god moderne optimaliserende kompilator skriver?

 

Det er kjent at robot handel med aksjer før gikk på milli sekunder. Nå går de på mikro sekunder.

 

4. ASM er raskere enn C som igjen er raskere enn C++. Selv har jeg sett eksempler på fraktaler kjøre 100 ganger raskere i ASM enn i C. Se for eksempel artikkelen i Micro Cornucopia #43 Sept-Oct 1988 side 22-&--#62; "Fast fractals". Noe å tenke på for dem som alltid skal ha nye maskiner med de raskeste prosessorene. Bruker du gode algoritmer kombinert med ASM kode, er det vanskelig å slå en 386 makin på tallknusing selv med dagen multicore GHz maskiner.

 

Kilde: http://www.diskusjon...post&p=13774067

 

Jeg kan skanne inn den artiklen og embedde den i et PDF dokument om dere ønsker å lese den.

 

No offence men jeg tror ikke lærerstabben ved UIO er spesielt gode til å progge i assembler. Da hadde de ikke jobbet der i utgangspunktet.

 

Det kan være riktig. Kanskje noen av de beste arbeider i banker eller programvarehus som jobber for banker.

 

Langt mer interesssant hadde det vært å lage et program som leser en RSS eller annen feed av aksjekurser fra nettet, beregner candle sticks http://multifinancei...edetsmusikk.pdf og implementerer mine proprietære percentilebands http://www.percentil...ries-asymmetric

 

Kritiske rutiner / tallknusing kunne da skrives i assembly.

Endret av Slettet+9871234
Lenke til kommentar

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

Laster...
×
×
  • Opprett ny...