Real-time applicatie en .NET GUI: Gaat dat goed?

[Specy]

Hoi,

In het kort: Veroorzaakt een .NET GUI latency-problemen voor een real-time applicatie op dezelfde pc?

Ik heb een audio-applicatie die met zeer weinig vertraging inkomende audio bewerkt en weer naar buiten stuurt (via ASIO, denk aan latencies onder de 10 ms waarvan slechts 3 ms voor de I/O is). Voor gebruikers is dit het enige programma dat draait op de pc, waardoor dit soort latencies haalbaar zijn zonder hiccups. De PC wordt opgestart met deze software en moet dan in principe jaren stabiel draaien.

De huidige GUI is geschreven in C++ en draait in hetzelfde proces. Net als de rest van de code is dit zo geschreven dat het geen hiccups veroorzaakt (geen memory-allocaties na opstarten e.d.).

Ik wil nu een losse GUI laten ontwikkelen (laten omdat ik zelf gewoon niet genoeg tijd heb om alles te kunnen doen), die in een los proces moet gaan draaien, en later ook op een tablet of telefoon gebruikt kan worden. Het bedrijf dat ik hiervoor benaderd heb stelt voor om dit in .NET te doen.

In het verleden heb ik erg slechte ervaringen gehad met .NET software (veel te veel geheugen-allocatie, memory fragmentation, garbage collector die soms de CPU volledig in beslag neemt en zo'n beetje alles stil zet). Wat ik wil weten - voordat ik een hoop geld uitgeef - is of een .NET GUI problemen zal gaan veroorzaken met mijn audio. Zelfs over een verhoging van de latency van 1 of 2 ms gaan mensen al klagen...

[Tharulerz]

Elke computer heeft toch 4 cores tegenwoordig, dus of 1 applicatie nu een volledige core inneemt of niet, dat zou je audio applicatie toch niet mogen voelen?

[Specy]

Tja, behalve dat ik zelf ook al meerdere cores gebruik. Mijn software heeft in het uiterste geval 3 outputs die elk 2 cores nodig hebben, gelukkig hoeven ze niet allemaal een lage latency te hebben dus ik kan wat 'spelen' met het zelf verdelen van de CPU-tijd. En het gaat draaien op een i7-4770K processor, die is zodanig snel dat ik wellicht voor 2 van de outputs met 1 core kan volstaan (dan heb ik er dus precies 4 nodig). Maar in ieder geval is het niet zo dat ik 1 van de cores volledig vrij kan maken voor de GUI. Verder: Als .NET allerlei rare dingen gaat doen (hele geheugen volgooien, swappen, ...) dan kan dat alsnog problemen veroorzaken voor het totale gedrag.

[MB113]

Kun je dit probleem niet aan hen opzadelen? Jij stelt de eis dat de latency niet hoger moet liggen dan de huidige gui, hoe of in welke taal ze dat doen is hun probleem. Zolang het niet in orde is hoef jij toch niet te betalen want het product voldoet niet aan de gestelde eisen. Of praat ik nu onzin?

[Specy]

@MB113: Dat kan idd. Maar als het niet goed gaat ben ik wel weer een hoop tijd verder en heb ik niks. En ik wil snel met een werkend produkt komen.

Als vooraf al duidelijk is of dit wel of niet kan heb ik dat uiteraard veel liever.

[ Voor 22% gewijzigd door Specy op 07-02-2014 16:33 ]

[Gomez12]

Het principe qua programmeren is : Hoe higher level language hoe oncontroleerbaarder het wordt.

Een .Net / Java doen aan garbage collection wanneer het hun uitkomt en niet wanneer het jou uitkomt.
Een .Net / Java hebben een extra laag qua verwerking die door andere dingen volgestopt kan zijn.

Het is voornamelijk de vraag hoe je het wilt gaan opzetten. Als .Net ook je Audio-afhandeling moet gaan doen dan heb je denk ik een grote uitdaging.
Maar als jij je eigen progje blijft behouden en de .Net enkel jouw progje aanstuurt dan is in ieder geval de audio op zich gegarandeerd (voor zover jij het in jouw progje garandeert). Ook al gaat de .Net 100% cpu trekken, jouw progje moet daar niet door gestoord worden (want elk proces kan 100% cpu trekken als het moet).

Dan houd je enkel nog over dat het indrukken van een knop -> geluidsverandering vertraging kan oplopen, maar is dat erg? Want dat is namelijk inherent aan .Net maar ook aan windows/multitasking etc. Wil je dat 100% afvangen dan moet je zo ongeveer DOS erop gaan zetten, want ongeveer alles daarna heeft gewoon een task-scheduler die roet in het eten kan gooien.

Een goeie .Net hoeft bijna geen latency te hebben, alleen vereist die dan wel veel geheugen / opstarttijd (alles simpelweg cachen) Het is en blijft een interpreted taal en tja, dat heeft gevolgen.
Het is alleen maar even de vraag of die gevolgen ook relevant zijn (op een p4 vast wel, maar op een redelijke huidige computer bijna nooit)

[Specy]

Het blijven losse applicaties. Maar goed, als iemand bijv. een browser opent kan dat best wat gehakkel veroorzaken, zelfs al draait het audio-proces in de hoogste prioriteit. Windows is nou eenmaal geen realtime os.. vandaar dus ook deze vraag.

[Gomez12]

Grote vraag is dan : is het mogelijk om bijv een eis van 4gb ram voor de .net app neer te leggen bij de gebruiker (4gb is waarschijnlijk zwaar overdreven, maar met een p4 512 mb zal het gaan hakkelen)

.Net heeft meer overhead dan c++, dus de systeemeisen gaan omhoog. Heb jij in c++ allemaal optimalisaties moeten doen voor mensen met lage systeemspecs dan gaat het moeilijk worden.

Waarom heb jij bijv geen memory allocaties na startup geschreven? Omdat iemand er echt een probleem mee had, of was het meer een theoretische optimalisatie? Want in .Net kan je wel de boel cachen, maar de gc kan langskomen als je niet genoeg geheugen hebt...

[Hydra]

Gomez12 schreef op vrijdag 07 februari 2014 @ 16:42:
Het principe qua programmeren is : Hoe higher level language hoe oncontroleerbaarder het wordt.

Een .Net / Java doen aan garbage collection wanneer het hun uitkomt en niet wanneer het jou uitkomt.

Dat is prima te ondervangen met object-pooling. Als er niks gedereferenced wordt, valt er niks te gc-en.

Een .Net / Java hebben een extra laag qua verwerking die door andere dingen volgestopt kan zijn.

Vind je zelf ook niet dat dit nogal een enorm vaag statement is? Door 'dingen' 'volgestopt'? En wat lost 4gb voor een gui op? Dan gaat een slecht systeem met memoryleaks hoogstens wat later over zn nek.

Een .net of Java gui naast een dergelijk low-level systeem is gewoon als het goed is een compleet non-issue.

[ Voor 6% gewijzigd door Hydra op 07-02-2014 19:14 ]

[Sircuri]

Specy schreef op vrijdag 07 februari 2014 @ 16:32:
@MB113: Dat kan idd. Maar als het niet goed gaat ben ik wel weer een hoop tijd verder en heb ik niks. En ik wil snel met een werkend produkt komen.

Als vooraf al duidelijk is of dit wel of niet kan heb ik dat uiteraard veel liever.

Met dit soort dingen moet "jij" enorm oppassen. Je wil iets hebben met bepaalde eisen. Als die eisen belangrijk zijn, moet je niet vervolgens aankomen met het feit dat het snel af moet. Hiermee gooi je je eigen glazen in. Een bedrijf zal dat ook zeker tegen je gebruiken mocht het tot een conflict komen.

Ik ben het dus helemaal eens met MB113. Laat het probleem bij de juiste partij liggen en ga er absoluut niet tussen zitten. Een gerechtelijk geschil gaat jaren duren en dan heb je ook nog steeds niets. (Spreek uit ervaring waarin een klant steeds eisen bleef stellen en het product uiteindelijk niet af kwam en ook niet 100% functioneerde zoals de klant het graag gezien had. geschil duurt ondertussen al 2 jaar en er lijkt voorlopig nog geen einde aan te komen.)

[R4gnax]

Gomez12 schreef op vrijdag 07 februari 2014 @ 16:42:
Het is en blijft een interpreted taal en tja, dat heeft gevolgen.

.NET code is nooit interpreted geweest.

.NET talen incl. C# compileren naar CIL bytecode die on demand naar native code gecompileerd wordt wanneer het op een doelsystem gedraaid wordt. Daarbij kan de gecompileerde code platform-specifieke optimalisaties mee pakken.

Je kunt een .NET assembly ook 'precompilen' naar native code met ngen.exe in de compiler tools. Nadeel is dan dat het niet meer 'portable' is tussen bijv. x64 en x86 architectuur.

Gomez12 schreef op vrijdag 07 februari 2014 @ 16:42:
Een .Net / Java doen aan garbage collection wanneer het hun uitkomt en niet wanneer het jou uitkomt.

De .NET garbage collector draait tegenwoordig op een aparte thread en houdt jouw programma nauwelijks meer op. Als je problemen krijgt met 'stotteren' in near real-time applicaties (bijv. videogames) dan zit dat eerder in de allocatie en het on-demand compileren, niet in garbage collection.

[Gomez12]

Sircuri schreef op vrijdag 07 februari 2014 @ 19:16:
[...]
Ik ben het dus helemaal eens met MB113. Laat het probleem bij de juiste partij liggen en ga er absoluut niet tussen zitten.

Moet je het probleem wel testbaar omschrijven.Geen inputlag is bijv een vage term, mag je 1ms inputlag hebben of 10ms of 100ms en hoe moet het gemeten worden?

Ik heb door de jaren heen genoeg bedrijven gezien die perfect alles kunnen loskoppelen / verdelen zodat 1 klik leidt tot 60 interne calls en elke call duurt max 1 ms, maar het eindresultaat is wel dat het max 60 ms kan duren. En als je dan hebt staan dat 1 call max 1ms mag kosten dan wordt er volledig aan voldaan...

Hydra schreef op vrijdag 07 februari 2014 @ 19:12:
[...]
Dat is prima te ondervangen met object-pooling. Als er niks gedereferenced wordt, valt er niks te gc-en.
[...]
Vind je zelf ook niet dat dit nogal een enorm vaag statement is? Door 'dingen' 'volgestopt'? En wat lost 4gb voor een gui op? Dan gaat een slecht systeem met memoryleaks hoogstens wat later over zn nek.

Object pooling zorgt dat je gc wellicht achterwege blijft (is ook nog twijfelachtig bij genoeg gevallen) maar omdat je dan weer grotere objecten gaat creeeren heb je weer meer kans op swapping.
In wezen is het basis probleem dat je niet meer 100% zelf het geheugenbeheer doet, daarom heb je genoeg headroom nodig zodat het framework het niet nodig vindt om in te grijpen.

R4gnax schreef op vrijdag 07 februari 2014 @ 19:44:
[...]
.NET talen incl. C# compileren naar CIL bytecode die on demand naar native code gecompileerd wordt wanneer het op een doelsystem gedraaid wordt. Daarbij kan de gecompileerde code platform-specifieke optimalisaties mee pakken.

Ok, dus de terminologie is anders, het punt blijft staan.

[...]
De .NET garbage collector draait tegenwoordig op een aparte thread en houdt jouw programma nauwelijks meer op. Als je problemen krijgt met 'stotteren' in near real-time applicaties (bijv. videogames) dan zit dat eerder in de allocatie en het on-demand compileren, niet in garbage collection.

Yep, daarom worden alle games ook gemaakt in .net
Een gc-run is gewoon "duur". En het is heel leuk dat die dure operatie in notepad nauwelijks merkbaar is, met een near-real time app is nauwelijk opeens wel erg duur.

[Sebazzz]

Bedenk wel dat je de .NET kan configureren dat deze de server GC gebruikt. Sowieso is er in .NET 4 en hoger het e.e.a. aan de GC en JIT veranderd, dus lees je daar even goed over in.

[armageddon_2k1]

Overigens lees ik dat je met audio aan de gang bent via ASIO.

Sinds de milleniumwisseling zijn computers al snel genoeg om op 96kHz 32bit fatsoenlijk low-latency audio te processen, dus vraag ik me af of je niet te veel te veel eisen stelt. Ik ga er voor de volledigheid even niet vanuit dat je 128 sporen o.i.d. gebruikt.

Het feit dat je meldt dat het het enige programma is dat draait en daarom zonder hiccups draait vind ik dan ook vreemd. Wat voor een enorm zwaar audioprogramma draai je dat dat nodig heeft? Ik heb hier een Pentium 4 uit 2002 welke zonder enige problemen makkelijk een 96kHzx32bit stereo track kan afspelen met een ASIO latency van 8ms. Dit heeft echter veel meer met de audio-interface en de HDD van doen dan de CPU zelf....

M.a.w..... ben je niet verkeerd aan het kijken?

[.oisyn]

^^^ dat. Je vraag zou 10 jaar geleden ontzettend relevant geweest zijn, maar computers zijn inmiddels wel een tikje sneller geworden. Zeker als je een Core i7 pakt zou ik me absoluut geen zorgen maken over enige inefficientie van de GUI.

[ Voor 15% gewijzigd door .oisyn op 07-02-2014 23:03 ]

[R4gnax]

Gomez12 schreef op vrijdag 07 februari 2014 @ 20:43:
Ok, dus de terminologie is anders, het punt blijft staan.

De terminologie is anders omdat het twee compleet verschillende zaken zijn. Een interpreted taal evalueert elke regel programma code één voor één. Een taal die JIT-compilatie toepast neemt een simpele, sterk in syntax gereduceerde, genormaliseerde bytecode en compileert die éénmalig on the fly naar native code die direct als één eenheid op de processor kan draaien zonder verdere tussenkomst van de compiler. De resulterende gecompileerde native code wordt in cache bijgehouden en bij toekomstige aanroepen meteen ingezet, zonder nog eens gecompileert te hoeven worden.

De performance characteristics van die twee zijn compleet verschillend en JIT-ted bytecode zit veel, maar dan ook veel dichter bij native code dan bij interpreted code. Daarnaast stap je ook nogal nonchalant over het punt heen dat je .NET's CIL bytecode kunt precompilen met ngen.exe en dus de extra kosten voor JIT-compilatie compleet kunt elimineren; je krijgt dan direct een assembly met native code.

Gomez12 schreef op vrijdag 07 februari 2014 @ 20:43:

Yep, daarom worden alle games ook gemaakt in .net
Een gc-run is gewoon "duur". En het is heel leuk dat die dure operatie in notepad nauwelijks merkbaar is, met een near-real time app is nauwelijk opeens wel erg duur.

Kort lijstje van succesvolle games gebouwd met .NET:

• Terraria
• Dust: An Elysian Tail
• Sol Survivor
• Super Meat Boy
• FEZ
• Magicka
• Bastion
• (etc. ; sowieso alles wat geport is van XBLA en dat zijn er nogal wat...)

Daarnaast zijn er heel veel triple A titles die op bepaalde punten .NET gebruiken. Als ik me goed herinner zijn delen van de UI van Fable 3 er mee geschreven, bijvoobeeld. Borderlands 2 gebruikt het trouwens ook.

(Oh en als finale; http://www.unrealengine.com/html5/ Zelfs JavaScript is tegenwoordig snel genoeg om Unreal 3 te draaien, ja...)


Ik schuif me aan bij .oisyn en armageddon_2k1 : tegenwoordig mag het gebruik van een .NET GUI echt geen latency problemen meer opleveren. Als het dat wel doet, dan heeft er iemand echt zitten prutsen (wat net zo goed bij C++ code kan gebeuren) of ben je op underpowered hardware aan het draaien.

[ Voor 8% gewijzigd door R4gnax op 08-02-2014 12:00 ]

[PrisonerOfPain]

R4gnax schreef op zaterdag 08 februari 2014 @ 11:44:
Kort lijstje van succesvolle games gebouwd met .NET:

• Terraria
• Dust: An Elysian Tail
• Sol Survivor
• Super Meat Boy
• FEZ
• Magicka
• Bastion
• (etc. ; sowieso alles wat geport is van XBLA en dat zijn er nogal wat...)

Dat zijn nu niet de echt de "iedere microseconde telt" 60Hz titels.

Daarnaast zijn er heel veel triple A titles die op bepaalde punten .NET gebruiken. Als ik me goed herinner zijn delen van de UI van Fable 3 er mee geschreven, bijvoobeeld. Borderlands 2 gebruikt het trouwens ook.

Geen enkele van die games heeft ook maar 1 regel runtime code in .Net geschreven - ik geloof er niets van.

Wat wij (en bijna ieder andere game engine) doen is onze tools in .Net schrijven en dat werkt prima. We laten de GUI in WPF draaien en hebben de game in een aparte C++ exe draaien die we in de WPF app embedden. Dat werkt prima.

Voor jou real-time eisen is het wellicht wat anders - kans is dat je gewoon al je cores wilt benutten maar wat je zou kunnen doen is met SetProcessAffinityMask je C++ code op N-1 cores te pinnen en de .Net app op de andere core (bijvoorbeeld).

Hoe ziet je CPU utilization er nu uit? Het draait onder windows - wat niet echt een real-time OS is, hoe ga je daar mee om? Disable je andere applicaties / services? Hoe afhankelijk ben je van de thread-scheduler op dit moment? Schets eens een beter beeld van het een en ander. En: wat voor processing doe je?

R4gnax schreef op zaterdag 08 februari 2014 @ 11:44:
(Oh en als finale; http://www.unrealengine.com/html5/ Zelfs JavaScript is tegenwoordig snel genoeg om Unreal 3 te draaien, ja...)

Een beperkte featureset van UE3.

[ Voor 6% gewijzigd door PrisonerOfPain op 08-02-2014 12:30 ]

[Specy]

Zoals gevraagd wat achtergrondinfo:

1. Programma doet vrij zware audio-processing, waarvoor ik sowieso meerdere cores van een snelle i5 of i7 nodig heb. Ik denk dat het verder niet echt relevant is wat de processing is...

2. Ik lever de hardware er zelf bij. Met Windows 7 Embedded erop. Dus ik heb (voor zover dat mogelijk is) volledige controle over de hardware, het OS en wat er verder aan andere software draait.

3. Huidige ervaring is dat de software prima draait op de meeste pc's (ik heb nu ook al software die iets vergelijkbaars doet maar waarbij ik de hardware niet zelf lever). Zolang er geen DPC-timingissues zijn zijn lage latencies prima te halen. Maar: Zodra iemand bijv. op dezelfde pc gaat browsen of een virusscanner laat lopen geeft dat al snel gehakkel als de latency 'on the edge' is.

4. De GUI moet continu geupdate worden. Omdat wat er in de audio gebeurt grafisch getoond moet worden. Denk aan 2 1280x800 schermen. (Mijn huidige C++ GUI gebruikt voor 1 1920x1200 scherm minder dan 5% CPU power op mijn 3 jaar oude i7 laptop).


Als er wat vertraging in de GUI of het effect ervan is is dat geen probleem. Maar als de - nogmaals, in een los proces draaiende - GUI gehakkel in mijn audio veroorzaakt wel.

De GUI zal sowieso op een lagere prioriteit draaien dan de processing, maar omdat Windows idd. geen real-time OS is kun je daar niet 100% op vertrouwen.

[ Voor 14% gewijzigd door Specy op 08-02-2014 14:35 ]

[farlane]

Als je het safe wilt spelen zou ik de bewezen techniek gebruiken, in dit geval dus C++. ( En daarbij accepteren dat je een duurdere developer nodig hebt? )

( Of misschien het risico bij de developer neerleggen als hij er van overtuigd is dat het wel kan, maar mocht het dan fout gaan zit je wel met je levertijdvertraging die je oploopt. )

[pedorus]

farlane schreef op zaterdag 08 februari 2014 @ 15:12:
Als je het safe wilt spelen zou ik de bewezen techniek gebruiken, in dit geval dus C++. ( En daarbij accepteren dat je een duurdere developer nodig hebt? )

De kans is groot dat er evengoed al andere dingen in .NET draaien, veel hardwarefabrikanten schrijven hun software ook deels in .NET bijvoorbeeld. Stel je voor om dit ook om te zetten naar C++?

offtopic:
Link terug naar meta-discussie

[Megamind]

Misschien een ander pad, maar kan je je DSP niet uitbesteden aan een dedicated ASIC of een FPGA? Die zijn uiteraard 100% realtime.

[PrisonerOfPain]

Specy schreef op zaterdag 08 februari 2014 @ 14:30:
Zoals gevraagd wat achtergrondinfo:

1. Programma doet vrij zware audio-processing, waarvoor ik sowieso meerdere cores van een snelle i5 of i7 nodig heb. Ik denk dat het verder niet echt relevant is wat de processing is...

Niet echt, was gewoon interesse van mijn kant

2. Ik lever de hardware er zelf bij. Met Windows 7 Embedded erop. Dus ik heb (voor zover dat mogelijk is) volledige controle over de hardware, het OS en wat er verder aan andere software draait.

[...]

4. De GUI moet continu geupdate worden. Omdat wat er in de audio gebeurt grafisch getoond moet worden. Denk aan 2 1280x800 schermen. (Mijn huidige C++ GUI gebruikt voor 1 1920x1200 scherm minder dan 5% CPU power op mijn 3 jaar oude i7 laptop).

GUI zal sowieso op een lagere prioriteit draaien dan de processing, maar omdat Windows idd. geen real-time OS is kun je daar niet 100% op vertrouwen.

Ik denk dat dit belangrijk is, je hebt nu zelf volledige controle over de setup (hardware + software) en ik verwacht dat dat redelijk belangrijk is voor mijn conclusie: zolang je die controle hebt kun je er waarschijnlijk prima voor zorgen dat het geheel netjes vloeiend draait. Volgens mij is het dan ook niet meer dan een kwestie van budgetten stellen, zorgen dat je zelf controle neemt over de GC en daar een bepaalde marge voor instellen.

Wat wij doen is bijvoorbeeld een aantal cores vrij laten omdat we weten dat bijvoorbeeld driver threads of hyper threading problemen veroorzaken. Het is jammer dat we dat niet preciezer kunnen doen dan "cores vrijhouden" (ipv bijvoorbeeld 10ms/f vrij laten voor de driver). Wellicht zou je er zelfs over kunnen denken om de UI op een slave machine te draaien?

Verder zou ik je aanraden om zelf voor je hier überhaupt aan begint een simpele .Net app te maken die wat simpele processing doet om te kijken wat voor invloed dat heeft - en kijken hoeveel je in kunt leveren aan die app.

[farlane]

pedorus schreef op zaterdag 08 februari 2014 @ 16:03:
[...]

De kans is groot dat er evengoed al andere dingen in .NET draaien, veel hardwarefabrikanten schrijven hun software ook deels in .NET bijvoorbeeld. Stel je voor om dit ook om te zetten naar C++?

offtopic:
Link terug naar meta-discussie

Hij geeft toch aan dat het nu C++ is, niet .NET? Wat valt er nog meer om te schrijven dan?

[edit]
Bovendien lijkt het me dat de software van de hardware fabrikanten die in het kritieke pad zitten zeker niet in .NET geschreven is.

[ Voor 12% gewijzigd door farlane op 08-02-2014 19:41 ]

[Grijze Vos]

Leg het als een harde eis neer bij de partij die het gaat implementeren. Kies een of twee belangrijke features, en laat ze die eerst bouwen in een prototype om te laten zien dat we ze denken dat werkt ook echt werkt.

Fail fast dus.

[pedorus]

farlane schreef op zaterdag 08 februari 2014 @ 19:22:
[...]

Hij geeft toch aan dat het nu C++ is, niet .NET? Wat valt er nog meer om te schrijven dan?

Als je programma niet goed werkt als er ook een .NET programma draait op dezelfde machine, dan zul je moeten zorgen dat er nul .NET programma's draaien op die machine.

[edit]
Bovendien lijkt het me dat de software van de hardware fabrikanten die in het kritieke pad zitten zeker niet in .NET geschreven is.

De GUI waar het hier om gaat zit ook niet op het kritieke pad.

BTW: In het kader van bewezen technieken: Gebruik je toevallig zeg Skype? Probeer het eens uit wat er gebeurd als je .NET Framework deïnstalleert.

[.oisyn]

Specy schreef op zaterdag 08 februari 2014 @ 14:30:
Zoals gevraagd wat achtergrondinfo:

1. Programma doet vrij zware audio-processing, waarvoor ik sowieso meerdere cores van een snelle i5 of i7 nodig heb. Ik denk dat het verder niet echt relevant is wat de processing is...

Als de audioprocessing zelf zo zwaar is is een gpgpu oplossing dan niet interessanter?

[farlane]

pedorus schreef op zaterdag 08 februari 2014 @ 21:50:
[...]
Als je programma niet goed werkt als er ook een .NET programma draait op dezelfde machine, dan zul je moeten zorgen dat er nul .NET programma's draaien op die machine.
[...]

Dat heb ik niet uit de vraag begrepen : volgens mij vraagt hij of het schrijven van de GUI voor zijn programma in .NET een probleem zou geven.

De GUI waar het hier om gaat zit ook niet op het kritieke pad.

In de situatie waar hij nu in zit wel, het is immers hetzelfde proces. Bovendien kan ik me voorstellen dat als je iets doet met low latency audio dat ook de GUI low latency moet zijn.

BTW: In het kader van bewezen technieken: Gebruik je toevallig zeg Skype? Probeer het eens uit wat er gebeurd als je .NET Framework deïnstalleert.

Ik bedoel niet dat .NET een onbewezen techniek is, maar dat zijn in C++ geschreven programma al heeft bewezen te werken en dus een minder groot risico is dan een nieuw ding maken met/op/in .NET.

Overigens gebruik ik geen Skype, maar zou je me kunnen vertellen wat de relevantie is?

[Specy]

Ik heb de afgelopen dagen wat tests gedaan met een oude pc (dus wel hele andere hardware dan wat ik straks ga gebruiken, en er staat Vista op), en daarop krijg ik zelfs al tikjes in de audio als ik met de muis over een Explorer-window beweeg. De echte hardware moet ik binnenkort binnen krijgen, ik denk dat ik jullie advies ga opvolgen om ze in eerste instantie te vragen om een programma wat alleen iets simpels doet maar wel flink wat op het scherm tekent.

In ieder geval lijkt niemand tot nu toe te zeggen dat het echt niet kan, dus we zullen het maar snel uitproberen.

C++ zou overigens ook kunnen, maar de GUI wordt zeer uitgebreid en moet er ook gelikt uitzien. Niet dat dat in C++ niet kan, maar ik kan me zo voorstellen dat je het in C# veel sneller voor elkaar hebt.

[.oisyn]

Specy schreef op zondag 09 februari 2014 @ 21:54:
Ik heb de afgelopen dagen wat tests gedaan met een oude pc (dus wel hele andere hardware dan wat ik straks ga gebruiken, en er staat Vista op), en daarop krijg ik zelfs al tikjes in de audio als ik met de muis over een Explorer-window beweeg.

En ligt dat aan de hardware of aan de programmacode?

[Specy]

Tja... Alles draait op de hoogst mogelijke prioriteit in Windows. Dus zover ik kan zien heb ik alles gedaan wat mogelijk is.

Ik moet het op wat andere hardware testen om te zien waar het aan ligt, ik heb eerder van gebruikers gehoord dat ze soortgelijke problemen hadden met concurrerende software.

In mijn eigen software heb ik het schrijven naar het scherm in kleinere stukjes opgedeeld (kost iets meer CPU) om dit soort issues op te lossen. Maar: Op dit testsysteem gaat het ook daarmee fout.

Ik heb de ASIO-latency nu ook wel heel erg krap ingesteld overigens (0.7 ms buffer), minimaal haalbare latency inclusief processing op dit systeem is nu 7 ms.

[ Voor 13% gewijzigd door Specy op 10-02-2014 00:32 ]

[Gomez12]

Specy schreef op maandag 10 februari 2014 @ 00:30:
Tja... Alles draait op de hoogst mogelijke prioriteit in Windows. Dus zover ik kan zien heb ik alles gedaan wat mogelijk is.

Ik moet het op wat andere hardware testen om te zien waar het aan ligt, ik heb eerder van gebruikers gehoord dat ze soortgelijke problemen hadden met concurrerende software.

In mijn eigen software heb ik het schrijven naar het scherm in kleinere stukjes opgedeeld (kost iets meer CPU) om dit soort issues op te lossen. Maar: Op dit testsysteem gaat het ook daarmee fout.

Ik heb de ASIO-latency nu ook wel heel erg krap ingesteld overigens (0.7 ms buffer), minimaal haalbare latency inclusief processing op dit systeem is nu 7 ms.

Moet je dan niet eerst eens gewoon kritisch naar je eigen stuk code laten kijken?
In wezen lees ik vooral dat je eigen software netaan draait en tja, een .net is bijna altijd zwaarder dan een goed opgezet C++ programma (hoeft niet veel zwaarder te zijn, maar als het nu al netaan is dan kan het kleinste beetje je over de grens trekken)

Helemaal als je nu al grappen als : Scherm in kleinere stukken opbouwen moet toepassen in C++ dan zou ik dit allemaal wel even melden bij het bedrijf waar je een test-traject mee wilt ingaan. Anders krijg je al snel appels en peren.
Schijnbaar kan jouw app ook niet "normaal"/standaard functioneren en vereist het allemaal kunstgrepen, verwacht dan niet dat regulier .Net dit wel 1-2-3 gaat doen. Dus vermeld dit wel even goed voordat ze de test-programmatuur gaan maken.

Maar aan de andere kant, als jij ook de hardware regelt dan is er minder aan de hand. Leg een pakket eisen neer bij de devvers voor machine x en schaf ondertussen voor je klanten machine x++ aan, zodat je wat headroom hebt voor fouten bij de programmeurs.

[Hydra]

Specy schreef op maandag 10 februari 2014 @ 00:30:
In mijn eigen software heb ik het schrijven naar het scherm in kleinere stukjes opgedeeld (kost iets meer CPU) om dit soort issues op te lossen. Maar: Op dit testsysteem gaat het ook daarmee fout.

Dus je gebruikt geen multithreading in je eigen applicatie?

[epic007]

Specy schreef op zondag 09 februari 2014 @ 21:54:
C++ zou overigens ook kunnen, maar de GUI wordt zeer uitgebreid en moet er ook gelikt uitzien. Niet dat dat in C++ niet kan, maar ik kan me zo voorstellen dat je het in C# veel sneller voor elkaar hebt.

Gelikte GUI in C++ is zeker mogelijk met een framework als Qt. Zeker met QML kan je snel mooie UIs maken.

[PrisonerOfPain]

Hydra schreef op maandag 10 februari 2014 @ 08:46:
[...]


Dus je gebruikt geen multithreading in je eigen applicatie?

Tweede post van Specy geeft aan dat er meerdere cores gebruikt worden.

Gomez12 schreef op maandag 10 februari 2014 @ 00:53:
[...]
Moet je dan niet eerst eens gewoon kritisch naar je eigen stuk code laten kijken?

Wat zou daar mis mee zijn dan? Dergelijke low-latency taken zijn gewoon enorm gevoelig voor kleine fluctuaties in systeem load. Zeker als de applicatie dan praktisch alle cores benut blijft er gewoon weinig plek over om eventuele pieken op te vangen.

[EddoH]

PrisonerOfPain schreef op maandag 10 februari 2014 @ 09:12:

Wat zou daar mis mee zijn dan? Dergelijke low-latency taken zijn gewoon enorm gevoelig voor kleine fluctuaties in systeem load. Zeker als de applicatie dan praktisch alle cores benut blijft er gewoon weinig plek over om eventuele pieken op te vangen.

Er kan toch zoveel mis zijn met de code? Vooral bij low latency audio processing en meerdere threads.
Thread synchronisation doormiddel van een sleep ipv wait/notify bijvoorbeeld. Ineffecient gebruik van je audio interface (blocking /non blocking read/writes) of een verkeerd afgestelde play/record callback threshold.
Ik zeg niet dat dit het geval is, maar het is een beetje kort door de bocht om te zeggen dat er weingi aan te doen is als alle cores 100% gebruikt worden.

Voor de TS: de gebruikte programmeertaal/platform hoeft in mijn ervaring geen invloed te hebben op de kwaliteit van je audio processing. Het komt vooral neer op de componenten die onder je controle vallen zo effeciënt mogelijk te gebruiken. Ter referentie: ik heb veel low latency audio code geschreven die op het Android platform werkt zonder dat ik controle had over de applicaties die het gingen gebruiken. Het moeilijkste is om je buffer afhandeling zo strak en effecient mogelijk te krijgen. De Java GC , memory allocaties en cpu gebruik van de applicaties waren een van de mindere problemen...

Met andere woorden: probeer niet te snel de schuld bij externe factoren te leggen, maar kijk eerst wat je zelf kan verbeteren en wees ook realistisch met je requirements. Een buffer van 0.7 ms (op welk niveau hebben we het hier over? Hw/driver/client sw? Welke buffers zitten er nog meer in het kritieke pad?) is natuurlijk erg krap.

[Hydra]

PrisonerOfPain schreef op maandag 10 februari 2014 @ 09:12:
Tweede post van Specy geeft aan dat er meerdere cores gebruikt worden.

Dan verbaast het me dat 'ie het tekenen van de GUI in 'stukjes' moet doen omdat het anders impact heeft.

[PrisonerOfPain]

Hydra schreef op maandag 10 februari 2014 @ 09:43:
[...]
Dan verbaast het me dat 'ie het tekenen van de GUI in 'stukjes' moet doen omdat het anders impact heeft.

Hoezo? Time-slicing word wel vaker gebruikt om werk op te delen in stukjes zodat je het uit kunt smeren, zeker als je niet zomaar op de thread scheduler kunt vertrouwen.

[.oisyn]

PrisonerOfPain schreef op maandag 10 februari 2014 @ 09:12:
Wat zou daar mis mee zijn dan?

Er kan vanalles mee mis zijn, waarom denk je per se dat dat niet het geval is? Weet jij meer dan wij?

Dergelijke low-latency taken zijn gewoon enorm gevoelig voor kleine fluctuaties in systeem load.

Dat klopt, 700us is ook absurd kort, dan is elke preempt al teveel. Hij sprak in zijn openingspost over minder dan 10ms en blijkbaar haalt ie met dat oude systeem al 7ms waarvan er waarschijnlijk nog wel iets af te schaven is.

Desalniettemin, je kan exact dezelfde symptomen veroorzaken met 10s latency door het vullen van de volgende buffer veel te laat te schedulen. <1ms latency ga je waarschijnlijk ook nooit halen, maar het feit dat ie dat nu ook niet doet impliceert niet dat ze code dan verder wel in orde zal zijn .

[PrisonerOfPain]

.oisyn schreef op maandag 10 februari 2014 @ 11:44:
[...]

Er kan vanalles mee mis zijn, waarom denk je per se dat dat niet het geval is? Weet jij meer dan wij?

Ik ben een stuk positiever ingesteld dan jullie zwartkijkers

[__fred__]

Windows is nooit geschreven als RT OS, en heeft dus ten aanzien van thread scheduling compromissen gesloten, waar je tegenaanloopt. Windows is een preemptive multitasking operating system, wat inhoudt dat het OS beslist om een thread te bevriezen en een andere te schedulen. Windows doet dit op basis van het quantum dat deels te beïnvloeden is (via Performance Options/Advanced in System Properties en dan bijstellen richting foreground applications, of programs ofzo.) en deels is vastgelegd in de geladen HAL in de kernel. Een goede richtlijn voor de runtijd van een slice is, voordat deze door het OS weer wordt afgebroken, is tussen de 10ms en 15ms.

Nou komt het veel vaker voor dat een thread zelf aangeeft dat het niets meer te doen heeft, of wacht op I/O o.i.d, dus het aantal OS preempts is relatief klein ten opzichte het aantal threads dat zelf besluit om het bijltje erbij neer te gooien omdat er op dat moment niets te doen is.

Omdat windows een preemptive multitasking OS is, en omdat de maximale runtijd van een thread 10 tot 15ms is, ben je in principe fucked indien er een andere thread is met gelijke of hogere prio, binnen of buiten je eigen process, die besluit om de maximaal gealloceerde tijd ook te gebruiken (even uitgaande van een single core processor zonder HT).

Waarom gaat het dan toch zo goed met je realtime applicatie? De meeste threads geven zelf nadat ze klaar zijn de controle terug aan het OS, je hebt meerdere cores, waardoor de kans dat je high priority proces wordt afgebroken een stuk kleiner is en gelukkig is het gros van de threads gewoon lekker aan het slapen en wil uberhaupt niet gewekt worden. Het probleem is dat je geen garanties krijgt. Je vertrouwt op het feit dat de PC verder niets te doen heeft. Zodra dat wel het geval is voor langer dan 10ms, dan is er kans op een hickup.

Het feit dat je aangeeft dat je de UI in C++ in stapjes bijwerkt, is een creatieve oplossing voor dit fenomeen: Zou je meer dan een aantal ms gebruiken in die ene thread dan loop je kans op delay in je audio.

.NET is niet anders dan elke andere thread die de processor gebruikt en jouw kostbare tijd zou kunnen afpakken en delay veroorzaken. Er zijn echter wel een aantal zaken die roet in het eten kunnen gooien: De JIT compiler is vanaf .NET 4.5 multi-core en kan dus je multi-core machine dichttrekken. (te ondervangen met ngen).
Daarnaast is er (naast de workstation garbage collector) de background-garbage collector: Deze is multi-threaded en draait op de hoogste threadprioriteit. Activeer deze dus niet in je .NET applicatie: alhoewel deze ongetwijfeld sneller is met garbage collecten, duwt ie je native threads met dezelfde of lagere prioriteit weg en geeft ook latency.

Mijn inschatting is dat je op een niet 100% belaste moderne multi-core machine prima uit de voeten zou kunnen met een .NET gui, zeker als deze in WPF of iets anders GPU accellerated is gemaakt voor de flashy effecten. Zit je echter op krappe single-core hardware of duw je echt 100% op alle cores voor je DSP berekeningen dan krijg je gegarandeerd hick-ups, maar die zou je ook krijgen met andere software die meer dan 10ms aan cycles van je high priority proces weet af te snoepen. Windows gaat namelijk die 10ms uitdelen als een andere thread erom vraagt.

[ Voor 3% gewijzigd door __fred__ op 10-02-2014 17:26 ]

[farlane]

Anyways, je kunt proberen wat je wilt maar realtime ga je het niet krijgen. Ik blijf er bij dat als het zo kritisch is dat je beter bij je bewezen verhaal kunt blijven.

Het kan natuurlijk een optie zijn om, omdat je de hardware zelf in de hand hebt, een realtime OS te pakken. Linux bijvoorbeeld is vrij simpel in een realtime smaak te krijgen.

[Specy]

Linux: Had ik graag gewild, maar er zijn voor zowel de geluidskaart als bepaalde andere features die ik nodig heb geen Linux-drivers... Dus voorlopig zit ik nog aan Windows vast.

Programma is multi-core, uiteraard zonder sleeps e.d., alle synchronisatie is zo strak mogelijk (anders zou ik ook nooit 7 ms aan latency kunnen halen - opgebouwd uit 3 ms audio nodig, 2 ms om berekeningen uit te voeren, en dan nog 2 voor het heen en weer sturen van de audio (de gemeten latency is echt tussen wat er de pc ingestuurd wordt en wat eruit komt).

Die 0.7 ms is inderdaad absurd kort, en ga ik denk ik ook niet echt gebruiken (tenzij ik het echt stabiel werkend zou kunnen krijgen).

Hiccups bij grote stukken tegelijk tekenen: Dit lijkt niet zozeer iets met de CPU-belasting te maken te hebben maar met communicatie met de video-chip. Nl: Ik teken eerst alles in het geheugen, in een lage-prioriteitsthread, en dat gaat prima. Maar als ik het hele scherm in 1 keer naar het window stuur (met de MFC functie BitBlt) gaat het op sommige pc's mis. Doe ik dat - zonder tussendoor te pauzeren - in kleinere blokjes (bijv. 32 lijntjes per call) dan gaat het wel prima. CPU load is eigenlijk zelfs hoger, maar de hiccups zijn weg.

Ik denk dat ik de tips van __fred__ ga opvolgen: Vooraf compileren, en die achtergrond-gc uitschakelen. Dat moet vrij snel te testen zijn...

[farlane]

Het zal wel bekend zijn inmiddels, maar ik zeg het toch nog maar even : ook al kun je het werkend krijgen op 7ms, je krijgt geen enkele garantie op een non-realtime OS : als het systeem besluit om wat anders te gaan doen kun je alsnog hiccups krijgen.

[Specy]

Ja. Maar er zijn mensen die mijn software al meerdere jaren hebben draaien zonder dat ze ooit een hiccup hebben opgemerkt. Dus met instellen wat het OS verder allemaal doet kun je dat - in ieder geval grotendeels - opvangen.

[R4gnax]

Specy schreef op woensdag 12 februari 2014 @ 13:23:
Ja. Maar er zijn mensen die mijn software al meerdere jaren hebben draaien zonder dat ze ooit een hiccup hebben opgemerkt. Dus met instellen wat het OS verder allemaal doet kun je dat - in ieder geval grotendeels - opvangen.

Om maar eens een gevleugelde uitspraak in de mond te nemen: "Geleverde prestaties in het verleden bieden geen garantie voor de toekomst."

[Merethil]

Specy schreef op woensdag 12 februari 2014 @ 13:23:
Ja. Maar er zijn mensen die mijn software al meerdere jaren hebben draaien zonder dat ze ooit een hiccup hebben opgemerkt. Dus met instellen wat het OS verder allemaal doet kun je dat - in ieder geval grotendeels - opvangen.

Om even niet meer de diepte in te gaan aangezien dat blijkbaar niet werkt, kan je dan niet van een i7 4770K naar een hexacore/octocore gaan oid?
Dan heb je meer dan genoeg ademruimte...