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

Mac & PC, lydkort, Logic Pro, Cubase, Pro Tools, Ableton Live og andet software.
Nyt svar
Medlemsavatar
Søren Dyhr
Medlem
Indlæg: 3859
Sted: Rødovre

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

Indlæg af Søren Dyhr »

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

--sd

Medlemsavatar
Pastorius
Forum Donator
Indlæg: 507

Indlæg af Pastorius »

Søren Dyhr skrev:
man 21. dec 2020 16:16
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.
--
Robert

Medlemsavatar
Søren Dyhr
Medlem
Indlæg: 3859
Sted: Rødovre

Indlæg af Søren Dyhr »

Pastorius skrev:
man 21. dec 2020 16:21
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

Medlemsavatar
Pastorius
Forum Donator
Indlæg: 507

Indlæg af Pastorius »

Søren Dyhr skrev:
man 21. dec 2020 17:20
Pastorius skrev:
man 21. dec 2020 16:21
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.
--
Robert

Medlemsavatar
benjisan
Medlem
Indlæg: 3413
Sted: Østerbro, København

Indlæg af benjisan »

Søren Dyhr skrev:
man 21. dec 2020 16:16
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 :)
Senest rettet af benjisan man 21. dec 2020 18:02, rettet i alt 1 gang.

Medlemsavatar
benjisan
Medlem
Indlæg: 3413
Sted: Østerbro, København

Indlæg af benjisan »

Søren Dyhr skrev:
man 21. dec 2020 17:20
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.

Medlemsavatar
Søren Dyhr
Medlem
Indlæg: 3859
Sted: Rødovre

Indlæg af Søren Dyhr »

benjisan skrev:
man 21. dec 2020 18:01
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

Medlemsavatar
benjisan
Medlem
Indlæg: 3413
Sted: Østerbro, København

Indlæg af 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 :)

Medlemsavatar
benjisan
Medlem
Indlæg: 3413
Sted: Østerbro, København

Indlæg af benjisan »

Pastorius skrev:
man 21. dec 2020 16:21
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! :-D

Medlemsavatar
TJJ
Forum Donator
Indlæg: 249
Sted: Danmark

Indlæg af TJJ »

benjisan skrev:
man 21. dec 2020 18:46
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.

Medlemsavatar
benjisan
Medlem
Indlæg: 3413
Sted: Østerbro, København

Indlæg af 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.
Senest rettet af benjisan tirs 22. dec 2020 11:01, rettet i alt 1 gang.

Medlemsavatar
TJJ
Forum Donator
Indlæg: 249
Sted: Danmark

Indlæg af 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.

Medlemsavatar
Søren Dyhr
Medlem
Indlæg: 3859
Sted: Rødovre

Indlæg af Søren Dyhr »

benjisan skrev:
tirs 22. dec 2020 10:34
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

Medlemsavatar
bluefonia
Forum Donator
Indlæg: 1191
Sted: Kerteminde, - sådan ca.

Indlæg af 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....
iMac i7 3.4Ghz 32 Gb · MacBook Air · Apollo Twin · Adam A7X · Logic / Studio One · Vintage Design M73D MKll · RNC 1773

Medlemsavatar
TJJ
Forum Donator
Indlæg: 249
Sted: Danmark

Indlæg af TJJ »

bluefonia skrev:
tirs 22. dec 2020 12:41
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 :)

Medlemsavatar
Søren Dyhr
Medlem
Indlæg: 3859
Sted: Rødovre

Indlæg af Søren Dyhr »

bluefonia skrev:
tirs 22. dec 2020 12:41
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

Medlemsavatar
Søren Dyhr
Medlem
Indlæg: 3859
Sted: Rødovre

Indlæg af Søren Dyhr »

Pastorius skrev:
man 21. dec 2020 16:21
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:
the19thbear skrev:
fre 1. jan 2021 19:50
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

Medlemsavatar
Søren Dyhr
Medlem
Indlæg: 3859
Sted: Rødovre

Indlæg af 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

Nyt svar