wie kan me eindelijk het verschil uitleggen tussen enigma 1 en 2?

[Gast MiLo]

Origineel bericht van: Obi Wan

Daarom dat een DM800 met zoveel brute kracht stronttraag opstart

Dat is het linux gedeelte, da's allemaal C. En dat is veel trager dan het zou kunnen zijn.

Een groot deel van Enigma2 is gewoon C++. Alleen de gebruikersinterface is in Python geschreven.

De laatste seconden van het booten, waar je de tandwieltjes ziet, dan is Python actief. Daarvoor is het allemaal gewoon linux en machinecode.

[Gast MiLo]

Origineel bericht van: Obi Wan

Kan iemand dit uitleggen waarom dit expliciet is gedaan.

De inschatting destijds was dat Enigma1 geschikt maken voor meerdere tuners een zwaardere opgaaf zou blijken dan helemaal opnieuw beginnen met gebruikmaking van andere technieken - waaronder Python.

Dus ik zou denken vanwege ontwikkeltijd. Ontwikkelen in Python is gewoon 10x sneller dan in C++, nog afgezien van de extra overhead die je op settopboxen bij ontwikkeling nog krijgt omdat je na compileren eerst nog de box moet flashen en resetten... Mijn auto-tagger algoritme bijvoorbeeld die ik in een uurtje of zo in elkaar geklust heb zou in C++ al snel een paar dagen duren.

Voor performance maakt het niet veel uit. De stukken waar Python gebruikt wordt zijn typisch user interface enzo. Het maakt echt niet uit of je 1 of 10 milliseconden moet wachten na een toetsklik.

Nou moet ik daar wel aan toevoegen dat de jongens van Enigma hier en daar de plank behoorlijk misgeslagen hebben, en dat komt de snelheid en stabiliteit niet ten goede.

Python is bijzonder geschikt voor embedded systemen, omdat het - in tegenstelling tot Java - heel efficient met geheugen omgaat, en zich op dat gebied voorspelbaar gedraagt. Enigma2 kan prima wekenlang draaien zonder dat het geheugen weglekt, en dat is voor een groot deel aan Python te danken.

[Gast MiLo]

Origineel bericht van: pieterg

Dat is niet gecompileerd tot assembly (zoals met c), maar tot bytecode. Dus het blijft traag

Voor de Intel is er een JIT compiler (Psyco) die de Python code runtime omzet naar machinecode. Voor de MIPS is die er niet, maar 't is wel een interessant idee...

Ik denk trouwens dat in de toekomst talen als Python (Ruby, Perl, ...) wel eens sneller kunnen gaan worden dan C++ code. Dit omdat het voor een interpreter mogelijk is om heel specifieke kennis over het platform van de eindgebruiker te hebben, waar een C++ programma die kennis vaak niet kan hebben.

Een simpel voorbeeld: Als ik het spelletje "Doom" geheel in C geschreven en die alle 3D gedoe helemaal zelf uitrekent, op mijn machine draai, dan zal die veel slechter presteren dan een in C# of Python geschreven versie die wel gebruik maakt van de dikke videokaart.

[Neptunus]

Heeft iemand de E2 draaien op een E1 box?

 

Indien ja, loopt het een beetje soepel?

[Gast bobelen]

new enigma draait op mijn 600 tot nu

probleemloos

[Erik Slagter]

Origineel bericht van: MiLo

Ik denk trouwens dat in de toekomst talen als Python (Ruby, Perl, ...) wel eens sneller kunnen gaan worden dan C++ code. Dit omdat het voor een interpreter mogelijk is om heel specifieke kennis over het platform van de eindgebruiker te hebben, waar een C++ programma die kennis vaak niet kan hebben.

Ik begrijp je punt, maar C(++) specifiek gecompileerd voor een bepaald platform en CPU(-versie), daar kan echt geen python of ruby tegenop qua performance. Je moet de C-code natuurlijk ook wel slim schrijven, wat ik totnutoe van enigma1 gezien heb, daarvan gaan mijn haren te bergen rijzen. Dat is een soort van visual-basic-in-C++ geschreven. Drama. Niet te lezen, traag en onnodig geheugenverbruik.

Persoonlijk had ik het heel erg op prijs gesteld als men enigma2 in C of C++ (maar dan wel ECHTE C++ en niet misbruik zoals enigma1) geschreven had. En dan een beetje efficiente code, zucht.

Nu zit ik met dat brakke python met vage foutmeldingen, stack backtraces op willekeurige momenten en vooral: traaaaaaaag. Zo'n processor moet echt veel sneller kunnen werken. Ik vind twee minuten booten niet acceptabel. Overigens kun je al heel snel tijdens het bootproces naar de box telnetten/ssh'en, dus aan linux ligt het niet. Het lijkt er op dat er een paar kernel modules heel lang nodig hebben om te loaden, dat is toch ook belachelijk?

[Obi Wan]

Ik sluit me hier helemaal bij aan

[Gast pieterg]

Origineel bericht van: Erik Slagter

Overigens kun je al heel snel tijdens het bootproces naar de box telnetten/ssh'en, dus aan linux ligt het niet. Het lijkt er op dat er een paar kernel modules heel lang nodig hebben om te loaden, dat is toch ook belachelijk?

Het is met name het inlezen van configs en skins enzo wat zo lang duurt.
Grote delen hiervan zijn ondertussen al overgezet in c++, dat scheelt een aantal seconden, maar uiteindelijk moeten er nog steeds ontzettend veel python objecten gegenereerd worden uit het resultaat, en dat kost veel tijd.

Verder is de e2 reactor (in een poging om de python code vanuit de enigma mainloop te laten draaien) verre van optimaal.

Ik zou niet voor python gekozen hebben.

Snelheid van ontwikkelen lijkt in eerste instantie een pre, maar je krijgt je typefouten pas runtime, niet compiletime zoals bij c/c++. (Ik weet van mezelf dat als m'n c++ code compileert, het voor 99% zeker is dat het ook werkt. Dus bij mijn ontwikkel stijl is c++ uiteindelijk sneller)

Ja, ik weet dat je testunits moet schrijven, maar dat heb ik e2 ontwikkelaars tot nogtoe niet zien doen.
Oftewel, de groene schermen zijn voor de gebruiker, niet voor de ontwikkelaar

[Gast MiLo]

Origineel bericht van: pieterg

Ja, ik weet dat je testunits moet schrijven, maar dat heb ik e2 ontwikkelaars tot nogtoe niet zien doen.

Sterker nog, ze hebben het zichzelf schier onmogelijk gemaakt om nog unittests te kunnen gebruiken.

De netcaster plugin heb ik zitten stabiliseren met unit tests, en het resultaat zit nu in de centrale repo. Ik krijg hem niet meer plat. Probleem is dat je voor de meest belachelijke dingen ineens enigma nodig hebt, zoals het inlezen van een lijstje files (wat os.listdir ook prima doet hoor), en dan wordt het verrekte lastig om nog unittests te schrijven die je gewoon op de PC kan draaien.

Ik zou wel degelijk voor Python gekozen hebben, maar ik zou de software "binnenstebuiten" hebben gemaakt ten opzichte van wat er nu is. Ik zou van enigma2 een library hebben gemaakt, en de main zou in Python zitten.

Dat maakt het veel eenvoudiger om met bijvoorbeeld fouten om te gaan. Als een plugin zich misdraagt, dan gooi je die plugin buiten, maar dan hoef je niet heel de software plat te gooien zoals enigma nu doet.

De "traagheid" van enigma2 heeft echt helemaal niks met Python te maken. Dat ligt gewoon aan de programmeurs.

[Erik Slagter]

Origineel bericht van: pieterg

Snelheid van ontwikkelen lijkt in eerste instantie een pre, maar je krijgt je typefouten pas runtime, niet compiletime zoals bij c/c++. (Ik weet van mezelf dat als m'n c++ code compileert, het voor 99% zeker is dat het ook werkt. Dus bij mijn ontwikkel stijl is c++ uiteindelijk sneller)

Dat is ook precies mijn bezwaar tegen geinterpreteerde talen. Het lijkt allemaal zo makkelijk en "snel", maar de ervaring leert dat het je veel te makkelijk wordt gemaakt om slechte code te maken (= onvoldoende foutdetectie/recovery en inefficient). C rulez (met -Wall ;-))

[sneupertje]

Super al die reacties; geloof alleen niet dat ik nu exact weet waarom een enigma 2 de voorkeur heeft, zeker gezien al de verhalen over slecht geprogde versies.... Uitdaging???

 

In ieder geval dank!

 

Arnold

[arnoldl]

tja het heeft zn voor en tegens (en voor en tegenstanders)

 

moet zeggen , dat ik de snelheid een groot nadeel vind..

maar eenmaal gewend hieraan valt het ook wel mee.

 

enigma1 was qua reactiesnelheid eigenlijk super , dan valt twee direct tegen bij de eerste toetsdruk...

 

maar eenmaal gewend aan twee..kan ik toch niet zeggen dat het niks is.

(met de juiste plugins) is het best een fijn systeem..

 

als ze nou alleen maar eens de ab reactiesnelheid konden verbeteren...

 

grtx

[Neptunus]

Het enige wat ik bij Enigma 1 mis is dat er niet automatisch bij een opname wordt onthouden waar je bent gestopt.

 

In Enigma 2 mis bepaalde functies in de webif zoals de mountmanager.

[Gast MiLo]

Origineel bericht van: Erik Slagter

...dat het je veel te makkelijk wordt gemaakt om slechte code te maken...

Van de andere kant wordt het je ook veel makkelijker gemaakt om goede code te schrijven, en je bezig te houden met het oplossen van je probleem in plaats van het bedenken van de juiste incantaties die als enige doel hebben om de compiler tevreden te stellen.

Volgens mij is er niet een of andere oppertaal die de beste is om elke taak in te doen. Ik mix daarom graag. In een vorig project gebruikten we C# voor UI, C++ voor een hoop "bitneuk" taken en nog wat assembly om hier en daar wat dingen te kunnen doen die de C compiler niet wou doen. De juiste tool kiezen spaart niet alleen tijd, maar levert uiteindelijk ook een beter product.

[Erik Slagter]

Origineel bericht van: MiLo

Origineel bericht van: Erik Slagter

...dat het je veel te makkelijk wordt gemaakt om slechte code te maken...

Van de andere kant wordt het je ook veel makkelijker gemaakt om goede code te schrijven, en je bezig te houden met het oplossen van je probleem in plaats van het bedenken van de juiste incantaties die als enige doel hebben om de compiler tevreden te stellen.

Ik vind dat juist een goede zaak. Op het moment dat je je een beetje verdiept in de taal en de compiler, zul je ook runtime minder verrassingen hebben. Geinterpreteerde talen onthouden je die ervaring (oftewel "het werkt toch?", als ik ERGENS een hekel aan heb!)