Hvor meget Ram - Jeg kom for skade at se den her:

[Søren Dyhr]

Fordi både placebo og bedøvelser, kan være den rigtige løsning?

--sd

[Pastorius]

Fordi både placebo og bedøvelser, kan være den rigtige løsning?

--sd

Nej, fordi løsning på for lidt RAM er mere RAM, og løsningen på alle mulige andre problemer ikke er mere RAM.

[Søren Dyhr]

Nej, fordi løsning på for lidt RAM er mere RAM, og løsningen på alle mulige andre problemer ikke er mere RAM.

Men det er så ikke lysende klart hvordan man diagnosticerer sig frem til at det rent faktisk forholder sig sådan - at RAM rent faktisk er for lille, og der er udtømt for alle andre plausible årsager til glitch'ene. Jeg har aldrig set at swappen rent faktisk er blevet blev brugt, når jeg havde sat bufferisze ned omkring 32 samples. Jeg har en SSD af første generation ... Hvad jeg til gengæld har noteret i de situationer er at grafikkortet står for ret meget af varmeudviklingen ... om det så tvinger clock'en til at skifte i CPU.

Nu har jeg jo rejst denne tråd fordi, at memory management nok har undergået noget forvandling nu hvor GPU og CPU i M1 deler memory plads, så kunne det jo også tænkes at behovet for at flytte data ud og ind af celler, er noget enklere, ved bare at indexere pladsen og pege på den når den skal bruges, i stedet for at sende den dekomprimeret serielt igennem bussen for at blive brugt et andet sted?

--sd

[Pastorius]

Nej, fordi løsning på for lidt RAM er mere RAM, og løsningen på alle mulige andre problemer ikke er mere RAM.

Men det er så ikke lysende klart hvordan man diagnosticerer sig frem til at det rent faktisk forholder sig sådan - at RAM rent faktisk er for lille, og der er udtømt for alle andre plausible årsager til glitch'ene. Jeg har aldrig set at swappen rent faktisk er blevet blev brugt, når jeg havde sat bufferisze ned omkring 32 samples. Jeg har en SSD af første generation ... Hvad jeg til gengæld har noteret i de situationer er at grafikkortet står for ret meget af varmeudviklingen ... om det så tvinger clock'en til at skifte i CPU.

Nu har jeg jo rejst denne tråd fordi, at memory management nok har undergået noget forvandling nu hvor GPU og CPU i M1 deler memory plads, så kunne det jo også tænkes at behovet for at flytte data ud og ind af celler, er noget enklere, ved bare at indexere pladsen og pege på den når den skal bruges, i stedet for at sende den dekomprimeret serielt igennem bussen for at blive brugt et andet sted?

--sd

Nej, hvis det havde været lysende klart, hvad performanceproblemer skyldes, så havde vi ikke haft denne diskussion.

Problemet er nok ældre end M1-chippenes indtog. Det stammer nok fra at OS'er (som Benjisan også kommer ind på) er begyndt i stigende grad at tage kontrollen over, hvad der ligger i RAM, så applikationerne ikke selv kan bestemme. Performanceprogrammerne kan kun se et øjebliksbillede, men de kan ikke se, om OS er klar til smide xGB allokeret plads væk for at gøre plads til de RAM din DAW gerne vil allokere. Mao. Selvom du har allokeret 80% af din RAM, kan det sagtens være at der er mere end 20% tilgængeligt hvis du får brug for det.

Det er svært at se hvor grænsen går. Man kan synes det er upraktisk, men alternativet ville være at man bare fik en hård fejl, langt tidligere end man nu løber ind i problemer.

Der hvor M1 muligvis er bedre, er fordi den har sin AI-processor, som ville være oplagt til at bruge til at genkende forbrugsmønstre og forudse, hvad der kan frigives af plads i RAM'en, hurtigere end det kan lade sig gøre nu. Fysisk vil det også kunne gå hurtigere, fordi man ikke skal forbi printet ved I/O mellem de forskellige komponenter i processoren.

[benjisan]

Fordi både placebo og bedøvelser, kan være den rigtige løsning?

Nej. Fordi Placebo og bedøvelse absolut intet har med RAM forbrug i en computer at gøre.

Du har en helt personlig og egen-minded agenda med den her tråd som jeg ikke kan hjælpe dig med.
Jeg vil gerne prøve at guide og komme med råd i forhold til de tekniske forklaringer angående hvordan en computer fungerer (ikke at jeg er noget orakel, men jeg har en grundlæggende forsåelse af tingene), men dine moralske -og meta konklusioner du prøver at gennemtvinge, dem står du selv for. Den kan jeg ikke hjælpe dig med at underbygge

[benjisan]

Jeg har aldrig set at swappen rent faktisk er blevet blev brugt, når jeg havde sat bufferisze ned omkring 32 samples.

Det er fordi at buffersize og RAM swap intet har (direkte) med hinanden at gøre.

[Søren Dyhr]

Det er fordi at buffersize og RAM swap intet har (direkte) med hinanden at gøre.

Nej men hvad udløser så et ægte behov for RAM, det siges at store sample biblioteker ... gør det, men hvorfor nu lige det?

--sd

[benjisan]

Fordi at den bedste og hurtigste måde at afvikle samples på er at loade dem alle ind i rammen med det samme. På den måde kan computeren få adgang til og sende dine samples afsted til afspilning hurtigst muligt, uden først at skulle loade dem ind via din disk, som er meget langsommere end rammen.
Så har du for eksempel en masse orkester sample biblioteker der fylder, lad os tage et rundt tal bare for eksemplet skyld (det kan variere utroligt meget), 500 MB per instrument og du har lavet et stykke musik der bruger 40 forskellige instrumenter i hvert deres samplebibliotek, så har du teoretisk set 20.000 MB samples der kan afvikles på ethvert givent tidspunkt. Har du over 20.000 MB RAM i overskud, så kan du få loadet samtlige samples ind i rammen som giver det bedste udgangspunkt for computeren til at kunne afvikle alle de samples, og det vil give computeren mere overskud til at kunne afvikle dit projekt mere flydende og uden problemer.
Har du nu ikke de 20.000 MB RAM i overskud bliver din computer og din DAW (og dit sample instrument) nødt til kun at loade dele af dine samples ind i rammen og loade resten ind efterhånden som behovet opstår. Dette kan gøres på mere eller mindre smarte måder som software programmørene har fundet på igennem tiden, men ligegyldigt hvad vil det gøre processen mere omstændig og langsommere da visse dele af dine samples så skal loades fra disken, som er en meget langsommere proces, og måske i sidste ende gøre at dit projekt ikke kan afspilles uden at det hakker og glitcher.

Dette har ikke noget med RAM swap at gøre! Det er noget helt andet, som jeg har forklaret tidligere

[benjisan]

Nej, fordi løsning på for lidt RAM er mere RAM, og løsningen på alle mulige andre problemer ikke er mere RAM.

LIGE præcis!

[TJJ]

Fordi at den bedste og hurtigste måde at afvikle samples på er at loade dem alle ind i rammen med det samme. På den måde kan computeren få adgang til og sende dine samples afsted til afspilning hurtigst muligt, uden først at skulle loade dem ind via din disk, som er meget langsommere end rammen.
Så har du for eksempel en masse orkester sample biblioteker der fylder, lad os tage et rundt tal bare for eksemplet skyld (det kan variere utroligt meget), 500 MB per instrument og du har lavet et stykke musik der bruger 40 forskellige instrumenter i hvert deres samplebibliotek, så har du teoretisk set 20.000 MB samples der kan afvikles på ethvert givent tidspunkt. Har du over 20.000 MB RAM i overskud, så kan du få loadet samtlige samples ind i rammen som giver det bedste udgangspunkt for computeren til at kunne afvikle alle de samples, og det vil give computeren mere overskud til at kunne afvikle dit projekt mere flydende og uden problemer.
Har du nu ikke de 20.000 MB RAM i overskud bliver din computer og din DAW (og dit sample instrument) nødt til kun at loade dele af dine samples ind i rammen og loade resten ind efterhånden som behovet opstår. Dette kan gøres på mere eller mindre smarte måder som software programmørene har fundet på igennem tiden, men ligegyldigt hvad vil det gøre processen mere omstændig og langsommere da visse dele af dine samples så skal loades fra disken, som er en meget langsommere proces, og måske i sidste ende gøre at dit projekt ikke kan afspilles uden at det hakker og glitcher.

Dette har ikke noget med RAM swap at gøre! Det er noget helt andet, som jeg har forklaret tidligere

Det er en rigtig god forklaring, tak
Jeg har ofte undret mig over, at jeg aldrig har haft problemer med kun at have 8 GB RAM. CPU dør altid før rammen her.

[benjisan]

Måske er det fordi du primært kører plugins og virtuelle instrumenter der bliver drevet af CPU'en og ikke skal loade samples.

Man skal tænke på den her måde:
Plugins og virtuelle instrumenter bliver drevet af CPU'en.
Sample instrumenter som fx Kontakt, EXS24 og Halion skal loade samples ind i rammen, men kræver ikke så meget af CPU'en for at fungere.

[TJJ]

Yes - det var også det, jeg fik ud af din gode forklaring
Og nu jeg tænker efter: Jeg har et projekt med 5 x strygere i Kontakt, som begyndte at knase. Bouncede bare og tænkte ikke mere over det - for jeg freezer og bouncer ofte pga. CPU-overload - men det giver jo mening, at RAM (også) blev udfordret.

[Søren Dyhr]

Man skal tænke på den her måde:
Plugins og virtuelle instrumenter bliver drevet af CPU'en.
Sample instrumenter som fx Kontakt, EXS24 og Halion skal loade samples ind i rammen, men kræver ikke så meget af CPU'en for at fungere.

Bravo, her faldt tiøren også for mig!

--sd

[bluefonia]

En vigtig ting man kan lære af denne tråd er, at man får de bedste svar, hvis man stiller de rigtige spørgsmål....

[TJJ]

En vigtig ting man kan lære af denne tråd er, at man får de bedste svar, hvis man stiller de rigtige spørgsmål....

Eller hvis man overhovedet ikke spørger om noget

[Søren Dyhr]

En vigtig ting man kan lære af denne tråd er, at man får de bedste svar, hvis man stiller de rigtige spørgsmål....

...den kom først da jeg så hvordan man lagde sine egne samples ind i EXS24, at jeg blev klar over at virtuelle instrumenter og samples var to forskellige ting. Jeg har aldrig brugt andre sample-afspillere end Alesis D4, fordi man rigtigt længe har prøvet at undgå at tage egentlige computer med på lyd-job, fordi Murphys lov har spøgt (den med hvis noget kan gå galt, så gør det)

--sd

[Søren Dyhr]

Nej, fordi løsning på for lidt RAM er mere RAM, og løsningen på alle mulige andre problemer ikke er mere RAM.

Men er for lidt RAM så altid den korrekte diagnose, eller kan man blive "thrown off the scent" ... jeg refererede til en video:



Hvor (han) sagde at, det meget ofte er periferi udstyr, der er skyld i at selv pænt kraftige CPU'er kunne tvinges ud i utålelige buffersize settings. Følgende dukkede op i en anden tråd:

Alle bud er lyder godt men vil også lige komme med mit: da jeg skiftede lydkort på min maskine, var det pludselig som at få en langt hurtigere maskine. Mener jeg gik fra at ha en buffer på 1024 til 128. Det skete da jeg gik fra et lille presonus lydkort til et rme babyface Pro. Rme driverne yder virkelig godt.
Derudover skal du nok også ha en ny maskine og synes også den nye M1 lyder som et godt bud. Og focusrite Scarlett serien er helt Ok. Vil bare lige tipse dig om at du burde få endnu mere ud af din nye maskine hvis du skifter til Rme.

Betyder det så at ... vi måske ville kunne forvente at den Neurale Engine tager hånd om udskiftning af mindre effektivt programmerede driveres kode, med noget som får selv den mindste Scarlett I/0 til ikke at "forstyrre" i nævneværdig grad?

Jeg syntes at huske at du var lidt inde på det i et svar, hvor du talte om RAM forbruget skulle ud i en revurdering? Ved du noget om den der Core ML programmering?

--sd

[Søren Dyhr]

Så er der et nyt partsindlæg i debatten her:



Den kommer ind på at man skal slette kilderne til renderinger, ellers vil de alligevel være loaded i hukommelsen....

--sd