Wer hat mehr? (Logiken)

[2ndsky]

Nur aus Interesse: Welche Logiken hast du verwendet, um deinen Rechner (welcher Typ?) mit 500 Logiken auszulasten?????

Das würde mich auch interessieren? Also wenn der EibPC 65000 mögliche Verknüpfungen kann, dann sollte doch ein normaler PC etwas mehr packen... außer der EibPC hat spezielle Hardware Bausteine für Logiken, doch da ein Programm, egal wo es läuft, nur aus Logiken besteht kann ich mir nicht vorstellen, dass ein normaler PC da abkackt. Evtl. bei der selbst erstellten Logikengine etwas verschwenderisch mit den Resourcen umgegangen?

[enertegus]

außer der EibPC hat spezielle Hardware Bausteine für Logiken

ne, eher spezielle Firmware.

[TRex]

seis drum,

die umfrage macht nur dann sinn, wenn klar ist wie gezählt werden soll. Und selbst dann hat sich mir der Sinn noch nicht erschlossen.

ICH BIN MIT MEINEM HS GLÜCKLICH, die Ressourcen mit Logiken auszuschöpfen wird mir vermutlich in diesem weltlichen Leben nimmer gelingen.

[Chris M.]

Ich weiß welche "eine" Logik u.a. auf so etwas kleinem wie einem Infineon TriCore läuft. Der hat wenige hundert MHz, ein paar MB und regelt im Bereich von Millisekunden.

So spricht der im Link zitierte Beitrag von Dipl.-Ing. C. Bock, Dr. M. Klüting, Dr. F. Rabenstein: ”Advanced Calibration Tools – An Essential Contribution to the Development Process of the Innovative New BMW V8 Petrol Engine”, 17. Aachener Kolloquium Fahrzeug und Motorentechnik 2008 von 12000 Applikationsgrößen, in einem Steuergerät von 2008, d.h. mit entsprechend schwachem Prozessor.
Eine Applikationsgröße ist übrigens so etwas wie eine Konstante, Kennlinie oder Kennfeld. Dazu kommen dann noch die ganzen Variablen.

Wenn also ein potenterer Computer bei weniger Aufgaben schon die Grätsche macht, stimmt etwas in der Architektur nicht.

[NilsS]

ICH BIN MIT MEINEM HS GLÜCKLICH, die Ressourcen mit Logiken auszuschöpfen wird mir vermutlich in diesem weltlichen Leben nimmer gelingen.

Da bist du aber bescheiden bei der Auswahl der Logiken

[enertegus]

Wenn also ein potenterer Computer bei weniger Aufgaben schon die Grätsche macht, stimmt etwas in der Architektur nicht.

Naja, das ist halt die Frage, wie lange/wie viel man entwickelt. Eine Skriptsprache ist wohl auf ihrer Ebene immer einfach zu realisieren, weil man auf was aufbauen kann, und dann auch einfach umzustetzen, bleibt aber in der Performance leicht Fakor 20 hinterher oderwegen mir auch mehr.
Meine Erfahrung: Wenn man sich bei einer Aufgabenstellung richtig "anstrengt", kann schon mal über Faktor 1000 an Geschwindigkeit gewonnen werden. Das kostet Geld und da sind wir wieder bei einer Grundsatzentscheidung.
Also wenn hier nach 500 Logiken manches etwas langsamer geht, ist das durchaus denkbar. Wenn dabei aber die Logiken in C programmiert werden müssen, dann tippe ich auch mal einfach auf die Architektur .
Daher die Frage an den Poster: Wie setzt Du denn die Logiken um?

[EIB-TECH]

Ich hab mir heute mal zwei Projekte vorgenommen, und mal mittels Doku die Zahlen festgestellt:

1. Projekt 1389 Logikbausteine
2. Projekt 1246 Logikbausteine
3. Projekt 1445 Logikbausteine

Es sind aber reine Logikbausteine....

Es handelt sich jeweils um Einfamilienhäuser

[saft6luck]

Zur Anzahl der Logiken kommt ja immer noch die maximal mögliche Datenrate, mit der Inputs eintreffen können ... und da ist der KNX-Bus schon eher eine Schlaftablette. Wenn man dann noch ein paar 100 Timer laufen hat (die sicherlich auch nicht alle gleichzeitig losschlagen werden) bleibt bei einem 100MHz PPC (z.B. MPC604) noch ne Menge Zeit zum Nichtstun.

Vermutlich wird ein Webserver oder die Gegensprechanlage ganz andere Anforderungen stellen.

[makki]

Einfache AW: sicher deutlich >101 wenn eine Logik (so lehrt es uns ja KNX) auch ein und/oder-Gatter ist
Für meine nächste Logikengine auf einer 700 MHz CPU wünsche ich mir das bitte auch, das sie nicht wegen einem 9,6KBit-Bus absauft Nicht das ich es besser könnte aber wünschen darf man ja..

Makki

[callidomus]

Nur aus Interesse: Welche Logiken hast du verwendet, um deinen Rechner (welcher Typ?) mit 500 Logiken auszulasten?????

bei mir ist es so das jede Logik einen eigenen Thread spendiert bekommt.
In einer Linux VM mit 64Bit hat das System ziemlich daran zu knabbern. (Ein Prozess mit 500 Threads). Bei meinem 32Bit Linux ist bei 300 Threads (durch OS limitiert) Schluss, dort war der EEE-PC aber auch schon ziemlich am schnaufen.
Es ist also weniger ein Thema der Komplexität der Logiken (die waren auch nur 'leer'), als ein Problem durch den 'massiven' Einsatz von Threads.
Bis jetzt habe ich noch keine wirklich komplexen Logiken damit erstellt getestet, da das Framework sehr mächtig ist und viel abhandelt.

so long

Marcus

P.S. Danke an alle, die bis jetzt an der Umfrage teilgenommen haben.

[Chris M.]

bei mir ist es so das jede Logik einen eigenen Thread spendiert bekommt.
[...]
Es ist also weniger ein Thema der Komplexität der Logiken (die waren auch nur 'leer'), als ein Problem durch den 'massiven' Einsatz von Threads.

Threads an sich sind kaum ein Problem, die sind ziemlich leichtgewichtig.
Das Problem ist, dass Python keine richtigen Threads kennt. Und wenn man Python wirklich parallel haben will, muss man dort zum Multiprocessing wechseln - was aber pro Ausführungsstrang einen kompletten Python-Prozess bedeutet => von den Ressourcen her sehr unschön.

Probier mal das gute alte Pre-Forking. D.h. bei der Programminitialisierung einfach ein paar Worker-Threads oder Prozesse forken und denen dann zur Laufzeit die jeweils aktuelle Logik zuweisen.
So sollte eine unbegrenzte Anzahl an Logiken bei konstanten Kosten möglich sein.

Oder auf C/C++ gehen. Da kostet ein Thread im Grunde nur einen weiteren Stack...

[makki]

Nun, bevor ich schmarrn erzähle sagte ich eigentlich lieber nichts. Am besten wäre sicher vorher eine einmonatige Schulung bei mkoegler (pthsem) o.ä. zu nehmen

Trotzdem zum Thema Threads, das ist (Resourcen vs. Effizienz wenn man keinen Octacore für beschäftigt) garnicht so ohne.
Chris meint glaube ich optimale (Kernel)Threads (also Prozesse) auf vielen unabhängigen Kernen. Das die bei HT garnicht so unabhängig sind ist eine andere Seite der Medaille.
Und das kostet in Py (geht gut) / Perl (bullsh**³ weil Pl verwechselt hier Prozess und Thread) & Co massig Speicher (den man evtl. nicht hat).. pth(sem) ist da (Linux-nativ) IMHO fast unschlagbar, parallelisiert zwar nicht unbedingt auf mehrere Kerne aber das ist in diesem Fall auch bei weiten nicht notwendig, ein 200MHz ARM schafft das locker (wenn effizient gemacht)

Wie Chris schon schrieb: wenn dann (genug zeit..) würde ich auch preforken und danach die Jobs auf die (User-mode!) Threads aufteilen. Die warten ja eh nur auf irgendwas, komplexe Rechenopertionen gibts ja nicht.. (Den Sonnenstand berechnet jede 32Bit CPU in 1/1000 Wimpernschlag..)

-> Also, ein Thread pro "Logikbaustein", um zum Thema zurückzuschwenken: IMHO Overkill²! Also angenommen die "reine Lehre" (aktuelles CPU&Kerneldesign ist nicht mehr so einfach, ich weiss) mit Kernel-Threads muss die arme CPU&OS ein paar MB umherschieben (dagegen: die machen das sch*** schnell) um 3 Bits zu vergleichen

Mehrere Prozesse (um mehrere Kerne zu nutzen) sollte man wenn dann nachlagern (braucht man für KNX/GA/HA IMHO nur nicht wirklich, weil das eigentlich auch ein 8Bit uC oder 8051 schafft 2-3 Werte unterhalb der Wahrnehmungsschwelle zu verarbeiten - wenn man es kann - ich nehme mich hier explizit aus ;p)

Jedenfalls, der mit Abstand verbreitetste Webserver funktioniert so und da hängt kein 9,6kBit Kindergarten dran Da kann man sich eigentlich alles abschauen von mpm (prefork) bis fastcgi/mod_perl..
Wenn ich die Zeit hätte würde ich das beim nächten Versuch auch so machen
so far..

Makki

[mkeil]

ACK makki.

der overhead um einen neuen thread aufzumachen braucht glaub ich mehr ressourcen als alles einfach sequenziell abzuarbeiten (und mit einer queue zu arbeiten). die wahrheit liegt wohl irgendwo dazwischen. eine queue die dann abgearbeitet wird. dazu einen threadpool mit ~20-30 threads, und dann einfach einkommende requests round-robin verteilen.
nicht zu verachten ist auch bei vielen threads das context switching. wenn du nur 1 oder 2 cores hast dann geht auch nur 1 bzw. 2 abeitsschritte wirklich parallel.

schau dir evtl. mal node.js an. arbeitet zwar nicht multithread aber dafür asyncron was I/O usw. betrifft und eignet sich prima für solche "ich hab nur kleine aufgaben, davon baer sehr viele" probleme.

[makki]

..
mit 64Bit ..

Gestern konnte ich mir es noch verkneifen aber das tolle 64-Bit bedeutet übrigens auch mindestens Faktor 2 an Overhead beim Kontext-Switch um 1 Bit mit einem anderen in einen Prozess/Kernel-Thread* zu vergleichen.. Bestenfalls..
Mehr ist nicht immer besser
(wir reden hier ja nicht von 16kB AES-CBC und genau da ist die ganze Multicore-64Bit-Kernel-Thread-Nummer halt nicht wirklich zielführend sondern mehr kontraproduktiv.., weil eine Bananen-CPU ggfs halt mehr schafft als ein Quadcore-i7)
Strom brauchen die Dinger auch..

Makki

Edit: @mkeil: die Wahrheit liegt sicher dazwischen, meine tests lagen aber so bei rund 5 "workern", die allles locker abfackeln könnten..

[Tessi]

Man kann natürlich mit Kanonen auf Spatzen schießen und sich dann beschweren, das die Kadenz so niedrig und die Munition so teuer ist...

Aber wahrscheinlich hält man die vielen Entwickler, die für Echtzeitaufgaben, da wo es wirklich wichtig ist, eben keinen PC mit Windoof o.ä. sondern einen simplen 16-Bit 40MHz Microcontroller mit Endlosschleife als OS einsetzen, für altmodische Spinner aus dem letzten Jahrtausend...

Jedem wie es ihm gefällt...