Hallo zusammen =^.^= wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann, also zum Beispiel auf einen AVR oder STM, also der Mikrocontroller ist gleichzeitig der Server. Momentan sind die Dateien für die Webseite auf einer SD-Karte gespeichert und werden einfach zum Client geschickt, sprich Java, CSS, HTML usw. Mit dem PHP wäre nur so ein "nice to have" , aber nicht notwendig, läuft auch so alles wie es soll. Danke schon mal für Eure Antworten, Fragen werden natürlich so gut es geht beantwortet =^.^= P.S. Ich hoffe, es ist der richtige Bereich für die Frage.
:
Verschoben durch Admin
Du könntest die Server-Logik auch in C/C++ als Teil des Webservers implementieren. PHP auf einem Mikrocontroller scheint ansonsten eher Gebastel zu sein. Und außer einer etwas abstrakteren Sprache hätte es gegenüber dick auch nicht viele Vorteile, oder?
PHP braucht dicke Kisten mit Betriebssystem. Meist auch noch, plus irgendeine Datenbank. Je mehr Ram, desto besser. Minimalgröße dürfte die Raspberry Klasse sein.
Hallo jemand, inwie weit mir PHP Vorteile bietet, kann ich nicht genau beantworten, da ich mit jemand zusammen das Projekt mache und er vorallem das mit der Webseite gemacht hat und mich gefragt hat, ob es eventuell möglich wäre. Aber du würdest davon abraten bzw. sagen, dass es nicht möglich ist?
Hallo Arduino Fanboy D. , wenn man die stärke eines RaspBerry benötigt, dann ist PHP wohl nichts. Da ein RaspBerry rausfällt,da ein RaspBerry ein viel zu großer Overkill ist, betrachtet auf das große Ganze. Ich danke für die Antworten =^.^=
Ich habe auf die schnelle zumindest keine PHP-Portierung für Mikrocontroller gefunden. Vielleicht gibt es sowas irgendwo, die Chancen sind aber gut, dass man dann auch viel mit dem PHP-Interpreter selbst kämpft. Die Portierung dürfte auch nicht ganz trivial sein. Ich persönlich würde obigen Ansatz wählen.
小さな猫の女の子 schrieb: > ob PHP auf einem Mikrocontroller laufen kann, also > zum Beispiel auf einen AVR oder STM, also der Mikrocontroller ist > gleichzeitig der Server. Selbst wenn es ein PHP für µC gäbe: wie sieht der gesamte Use-Käs aus? z.B. "wie kommt" ein potenzieller Benutzer denn auf die WebSite? -> Aha, Du brauchst einen TCP/IP Stack nebst WebServer auf dem µC. Auch einen "Stecker wo das Internet rein geht"(;) solltest Du vorsehen... Kann man alles bauen (z.T. in den verfügbaren RTOS Portierungen enthalten), macht aber vermutlich nicht viel Sinn. Wie bereits von Arduino Fanboy D. empfohlen: RPi wäre wohl (so denn der Use-Käs wirklich so ist wie ansatzweise beschrieben) sinnvoll! VG Stephan und 3 匹の猫からの挨拶
Es gibt schon Durchaus fertige TCP/IP-Stacks vor allem für entsprechende STM32F4xx. Und mit entsprechenden Baustein geht das auch am AVR, siehe Arduino Ethernet Shield. Je nach Nutzerzahl und sonstiger Elektronik ist ein Raspberry da echt ein Overkill. Und es geht auch ohne RTOS.
Hallo Stephan, ich komme mit deiner Antwort nicht so ganz zurecht. Stephan schrieb: > Selbst wenn es ein PHP für µC gäbe: wie sieht der gesamte Use-Käs aus? > z.B. "wie kommt" ein potenzieller Benutzer denn auf die WebSite? -> Aha, > Du brauchst einen TCP/IP Stack nebst WebServer auf dem µC. Auch einen > "Stecker wo das Internet rein geht"(;) solltest Du vorsehen... > Kann man alles bauen (z.T. in den verfügbaren RTOS Portierungen > enthalten), macht aber vermutlich nicht viel Sinn. Soll ich dazu sagen, wie es bei mir momentan abläuft oder war das nur ein Beipiel von dir wie es womöglich aussieht oder aussehen soll? Mit RTOS ist Multitasking gemeint oder? Stephan schrieb: > Wie bereits von Arduino Fanboy D. empfohlen: RPi wäre wohl (so denn der > Use-Käs wirklich so ist wie ansatzweise beschrieben) sinnvoll Das verstehe ich von deiner Antwort, aber da muss ich leider dazu sagen, dass ein RaspBerry rausfällt, da belasse ich es so wie es momentan ist. Grüße an die Katzen zurück =^.^=
小さな猫の女の子 schrieb: > also der Mikrocontroller ist > gleichzeitig der Server. Der Webserver ist da meist gleich das Hauptprogramm. Da werden auch selten Dateien abgerufen, sondern die Webseite dynamisch erzeugt. Dann kann man gleich die Funktionalität in den Server einbauen.
Hallo jemand, das ist bei mir der Fall, der RaspBerry ist für meine Anwendung ein absoluter Overkill. Zumal wir eine eigene Platine erstellen und per Hand löten. Auch HDMI oder so wird nicht benötigt.
jemand schrieb: > Es gibt schon Durchaus fertige TCP/IP-Stacks vor allem für entsprechende > STM32F4xx. Und mit entsprechenden Baustein geht das auch am AVR, siehe > Arduino Ethernet Shield. Je nach Nutzerzahl und sonstiger Elektronik ist > ein Raspberry da echt ein Overkill. Und es geht auch ohne RTOS. Was hat das mit PHP zu tun? TCP/IP Stacks sind schon "ewig" auf Mikrocontrollern verfügbar (Damals noch mit ISA-Netzwerkkarten als Netzwerkzugang). Dann kamen solche Sachen wie "Siteplayer" oder Lantronix "xport" auf den Markt. Das war vor ca. 20 Jahren. php braucht einen Interpreter, und der kostet Kapazität, die erst aber einer bestimmten Controller-Größe vorhanden ist.
小さな猫の女の子 schrieb: > wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann, Schau dir an wie CGI funktioniert. Dann geht es.
Ich mache seit Jahren (fast) alle meine Microcontroller-Projekte mit dem PocketBeagle bzw. OSD3358. Die 20-30€ die das pro Stück mehr kostet hole ich dadurch rein, dass da einfach Linux/Debian drauf läuft, ggf. auch mit WiFi-Support. Und wenn man will installiert man einfach Apache + PHP. Das spart hunderte Stunden Entwicklungszeit und Debug-Schnittstellen. Selbst hardwarenah, weil der Linux-Kernel für fast alle Schnittstellen und Funktionen schon APIs bereitstellt und oft für interessante Chips sogar schon Treiber. Und echte Real-Time brauchen die wenigsten Anwendungsfälle. Manchmal kann man GPIOs oder I2C oder SPI sogar auch aus Shell-Scripts bedienen. Irgendwo ab ein paar tausend Stück gibt es natürlich einen Break-Even über dem ein dedicated-Controller mit RTOS billiger ist. Ein anderer Faktor ist wenn das Device batteriebetrieben und möglichst klein sein soll. Dann stößt man mit diesem Ansatz an Grenzen.
:
Bearbeitet durch User
Hallo Nikolaus S. und Nick M. , ich werde mir mal CGI anschauen, ob mir das weiterhilft. Der PocketBeagle ist auch interessant, aber soweit ich gesehen habe, eventuell für zukünftige Projekte. Danke für die ganzen Antworten =^.^=
STK500-Besitzer schrieb: > jemand schrieb: > >> Es gibt schon Durchaus fertige TCP/IP-Stacks vor allem für entsprechende >> STM32F4xx. Und mit entsprechenden Baustein geht das auch am AVR, siehe >> Arduino Ethernet Shield. Je nach Nutzerzahl und sonstiger Elektronik ist >> ein Raspberry da echt ein Overkill. Und es geht auch ohne RTOS. > > Was hat das mit PHP zu tun? > TCP/IP Stacks sind schon "ewig" auf Mikrocontrollern verfügbar (Damals > noch mit ISA-Netzwerkkarten als Netzwerkzugang). > Dann kamen solche Sachen wie "Siteplayer" oder Lantronix "xport" auf den > Markt. Das war vor ca. 20 Jahren. > php braucht einen Interpreter, und der kostet Kapazität, die erst aber > einer bestimmten Controller-Größe vorhanden ist. Das war auf Stephans Beitrag bezogen, der ja wegen TCP/IP direkt auf einen Raspberry gehen wollte.
Wie viel Nikolaus S. schrieb: > Ich mache seit Jahren (fast) alle meine Microcontroller-Projekte > mit dem PocketBeagle bzw. OSD3358. Die 20-30€ die das pro Stück mehr > kostet hole ich dadurch rein, dass da einfach Linux/Debian drauf läuft, > ggf. auch mit WiFi-Support. Und wenn man will installiert man einfach > Apache + PHP. > Das spart hunderte Stunden Entwicklungszeit und Debug-Schnittstellen. > Selbst hardwarenah, weil der Linux-Kernel für fast alle Schnittstellen > und Funktionen schon APIs bereitstellt und oft für interessante Chips > sogar schon Treiber. Und echte Real-Time brauchen die wenigsten > Anwendungsfälle. Manchmal kann man GPIOs oder I2C oder SPI sogar auch > aus Shell-Scripts bedienen. > Irgendwo ab ein paar tausend Stück gibt es natürlich einen Break-Even > über dem ein dedicated-Controller mit RTOS billiger ist. Ein anderer > Faktor ist wenn das Device batteriebetrieben und möglichst klein sein > soll. Dann stößt man mit diesem Ansatz an Grenzen. Wie viel Zeit man damit So spart, hängt auch mit der Übung auf Mikrocontrollern zusammen, die man so hat. Ich bin mir ziemlich sicher, dass ich insbesondere Kleinkram mit einem Mikrocontroller schneller lösen könnte.
小さな猫の女の子 schrieb: > wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann, also > zum Beispiel auf einen AVR oder STM, Nein. PHP ist ein, wie bei heutigen Mausschubsern üblich, Rechenleistung und Resourcen verschwendendes Monster, dass vor allem von seiner Umgebung lebt, also den per Library hinzugezogenen Funktionalitäten die ein ganzes Unix/Windows ähnliches Betriebssystem erfordern. Kleinster Prozessor dafür ist so was wie ein rPi.
Ich habe mal einen Webserver fuer einen AVR geschrieben. Dieser Webserver kann die Seiten dann ja auch gleich so erzeugen wie es sein soll. Wir hatten damals JSON anfragen fuer Hardware Variablen verwendet. php macht keinen Sinn. Wann verwendet man php ? php bleibt in einem Session kontext, und verschleiert die Konstruktion der Seiten. Aus einer Datenbank wird eine kontextabhaengige Seite. Bei einem controller genuegt ja ein einziger Kontext. Dh ein Rechner auf's mal, keine parallelen Verbindungen. Irgendwelche Rechnereien lagert man gerne per Javascript an den PC aus. Der hat genuegend Leistung uebrig. Wir hatten den Webserver auf AVR an einer seriellen Schnittstelle. Ein Ethernet mit Stack haette keinen Sinn gemacht.
MaWin schrieb: > 小さな猫の女の子 schrieb: > >> wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann, also >> zum Beispiel auf einen AVR oder STM, > > PHP ist ein, wie bei heutigen Mausschubsern üblich, Rechenleistung und > Resourcen verschwendendes Monster, dass vor allem von seiner Umgebung > lebt, also den per Library hinzugezogenen Funktionalitäten die ein > ganzes Unix/Windows ähnliches Betriebssystem erfordern. > Kleinster Prozessor dafür ist so was wie ein rPi. jaja, die ganzen Mausschubser, die das gesamte Backend von Facebook geschrieben haben ... was für ein Quark! In erster Linie ist PHP einfach nur eine Skriptsprache. So wie Python, Pearl und Javascript. Ob man Libraries benötigt hängt vom Einzelfall ab, ich dachte gerade hier wäre dieses Konzept bekannt!? Außerdem hat PHP schon immer ne ordentliche CLI und ist viel mehr als nur eine Templateengine. Auf nem Mikrokontroller hat PHP für mich aber trotzdem nichts zu suchen. Gerade weil ich so viel damit zu habe, aber auch weil ich gar keine keine Notwendigkeit erkennen kann. Um Daten zum Client zu schicken braucht es weder Javascript noch HTML noch CSS. Da genügt einfaches JSON.
PHP ist Overkill.. PHP wird zur Laufzeit übersetzt und man könnte rein theoretisch ein Script nativ vorher kompilieren. Und allein das dann auszuführen wäre wohl schon zuviel für eine MCU. Den einzigen Vorteil den PHP hat ist das es mit seinen ganzen Modulen als Schnittstelle dienen kann. Ich denke mal man müsste das vielleicht in Lua oder Micropython nachbilden. Am besten in C. Das kommt auf die Applikation an, dann vielleicht nodejs (nur gehört) oder so.
ThomasW schrieb: > Da genügt einfaches JSON. Dafür genügt das HTTP das sowieso schon da sein muss. Und für den Austausch in beide Richtungen PUT und GET. Einfacher gehts nicht. Und wenn man kapiert hat wie CGI funktioniert (was simpel ist) dann bekommt man das ohne Bloatware auf dem µC zum laufen.
Nick M. schrieb: > ThomasW schrieb: > >> Da genügt einfaches JSON. > > Dafür genügt das HTTP das sowieso schon da sein muss. > Und für den Austausch in beide Richtungen PUT und GET. > Einfacher gehts nicht. > Und wenn man kapiert hat wie CGI funktioniert (was simpel ist) dann > bekommt man das ohne Bloatware auf dem µC zum laufen. Ich glaube, ich würde es sogar noch einfacher machen: statt nem PUT ein GET mit query-Parametern (dafür findest du reichlich fertige Beispiele für nen ESP. Das bekommt sogar ein Anfänger in C/C++ hin). Ist eben immer die Frage, was brauchst du wirklich und was muss das Teil am Ende alles können. Das hat der TE aber leider nicht so genau beschrieben.
Guten Abend zusammen, Nick M. schrieb: > Und für den Austausch in beide Richtungen PUT und GET. > Einfacher gehts nicht. Momentan läuft das auch so ab, es wird ein GET angefordert vom Client und darauf wird geantwortet und dann werden eben neue Daten oder eben die Dateien für die Webseite gesendet. Ansonsten macht der Mikrocontroller nichts oder etwas anderes, da die Webseite lokal beim Client läuft. ThomasW schrieb: > Ist eben > immer die Frage, was brauchst du wirklich und was muss das Teil am Ende > alles können. Das hat der TE aber leider nicht so genau beschrieben. Ich kann auch nicht genau beantworten, was das PHP machen soll oder für was es verwendet wird, da ich mich damit nicht auskenne. Die Frage kommt von meinem Kollegen mit dem ich das Projekt zusammenbetreibe. Er hat auch die Dateien für die Webseite geschrieben. Wie im Einganspost geschrieben funktioniert alles auch und das PHP ist keine Vorraussetzung, es geht mehr darum, ob es prinzipiell möglich ist, egal was das PHP am Ende bezwecken soll. Aber so wie es klingt, ist die Leistungssärke eines Pies notwendig, außer ich habe jetzt etwas übersehen oder überlesen.
Für einen µC ist PHP totaler Overkill. Wie schon gesagt, reich eine Session meist aus. Die auszugebenden Websites sind hauptsächlich statisch mit eventuell variablen Werten. Datenbankzugriffe gibt es nicht. Ein zeitgemäßes Design lässt sich mit Javascript und CSS machen.
小さな猫の女の子 schrieb: > Ich kann auch nicht genau beantworten, was das PHP machen soll oder für > was es verwendet wird, Im Augenblick muss ja für eine Änderung der "Webseite" oder der Funktionalität die Firmware für den Controller neu übersetzt und geflasht werden. Das soll wohl entfallen. Blöd ist, das es eigentlich keine normale Dateien gibt.
小さな猫の女の子 schrieb: > außer ich habe jetzt etwas übersehen oder überlesen. So langsam, kommst du mir etwas quengelig vor, als wollte es dir nicht in den Kopf, dass PHP auf µC fürchterlich unsinnig ist. Dirk B. schrieb: > Im Augenblick muss ja für eine Änderung der "Webseite" oder der > Funktionalität die Firmware für den Controller neu übersetzt und > geflasht werden. Dagegen gibts sd-karten und SPIFFS Ja, man kann damit nicht jede Änderung abfangen, aber zumindest alles, was mit dem Aussehen zu tun hat.
Sorry, aber für einen brauchbaren Webserver mit PHP und MySQL würde ich zu einem Atom raten. Ein Raspi ist da zu schwach auf der Brust.
Ergänzug: Posfix, etc. und paar nette Tools gehören ohnehin auf eien Webserver mit drauf.
Arduino Fanboy D. schrieb: > So langsam, kommst du mir etwas quengelig vor, als wollte es dir nicht > in den Kopf, dass PHP auf µC fürchterlich unsinnig ist. Das tut mir natürlich leid, so wollte ich nicht klingen. Ich habe das auch schon verstanden, dass es unsinnig ist bzw. nicht möglich. Arduino Fanboy D. schrieb: > Dagegen gibts sd-karten Und so wird es momentan gemacht, dort liegt eine Java Datei und CSS und Fonts oder wie das heißt und die werden dem Client nach einer GET Anfrage geschickt und die Seite läuft lokal bei dem Client. Ich wollte lediglich die anderen Fragen beantworten, vielleicht wäre ja noch etwas interessantes dabei rausgekommen.
Etwas moderner wären noch Websockets, auch das geht mit Mikrocontrollern. Und auch ein REST API kann Daten liefern. Es wird nur häufig auf geänderten Code hinauslaufen und damit sind Änderungen nicht so einfach wie auf einem dickeren OS. Vielleicht geht mit microPython mehr, aber damit habe ich mich noch nicht näher beschäftigt.
ThomasW schrieb: > jaja, die ganzen Mausschubser, die das gesamte Backend von Facebook > geschrieben haben ... was für ein Quark! Ja. > In erster Linie ist PHP einfach nur eine Skriptsprache. So wie Python, > Pearl und Javascript. Ob man Libraries benötigt hängt vom Einzelfall ab, > ich dachte gerade hier wäre dieses Konzept bekannt!? Außerdem hat PHP > schon immer ne ordentliche CLI und ist viel mehr als nur eine > Templateengine. Äh... räusper Verzeihung, aber... hüstel nein. Leider... machen wir das doch einfach mal in Zahlen:
1 | /usr/bin/php7.2 |
2 | linux-vdso.so.1 (0x00007ffcc03f8000) |
3 | libargon2.so.0 |
4 | libresolv.so.2 |
5 | libz.so.1 |
6 | libpcre.so.3 |
7 | libm.so.6 |
8 | libdl.so.2 |
9 | libxml2.so.2 |
10 | libssl.so.1.1 |
11 | libcrypto.so.1.1 |
12 | libsodium.so.23 |
13 | libc.so.6 |
14 | libpthread.so.0 |
15 | /lib64/ld-linux-x86-64.so.2 (0x00007fbcbcb68000) |
16 | libicuuc.so.60 |
17 | liblzma.so.5 |
18 | libicudata.so.60 |
19 | libstdc++.so.6 |
20 | libgcc_s.so.1 |
21 | /usr/bin/perl5.26.1 |
22 | linux-vdso.so.1 (0x00007ffea6b6c000) |
23 | libdl.so.2 |
24 | libm.so.6 |
25 | libpthread.so.0 |
26 | libc.so.6 |
27 | libcrypt.so.1 |
28 | /lib64/ld-linux-x86-64.so.2 (0x00007f4f667ed000) |
29 | /usr/bin/ruby2.5 |
30 | linux-vdso.so.1 (0x00007ffcffb99000) |
31 | libruby-2.5.so.2.5 |
32 | libc.so.6 |
33 | libpthread.so.0 |
34 | libgmp.so.10 |
35 | libdl.so.2 |
36 | libcrypt.so.1 |
37 | libm.so.6 |
38 | /lib64/ld-linux-x86-64.so.2 (0x00007fb90ecfb000) |
39 | /usr/bin/python3.8 |
40 | linux-vdso.so.1 (0x00007fff06bda000) |
41 | libc.so.6 |
42 | libpthread.so.0 |
43 | libdl.so.2 |
44 | libutil.so.1 |
45 | libm.so.6 |
46 | libexpat.so.1 |
47 | libz.so.1 |
Wissende sehen: PHP benötigt leider immer noch viel mehr Libraries als andere Skriptsprachen. Ich persönlich habe da so eine Idee, woran das liegt, aber als offensichtlicher PHP-Könner kannst Du mir das sicher besser begründen. ;-)
Sheeva P. schrieb: > Wissende sehen: PHP benötigt leider immer noch viel mehr Libraries als > andere Skriptsprachen. Ich persönlich habe da so eine Idee, woran das > liegt, aber als offensichtlicher PHP-Könner kannst Du mir das sicher > besser begründen. ;-) Benötigt PHP die wirklich, oder wurden die vorm Compilieren ausgewählt? Schau dir mal die ganzen Schalter im configure an! Und zweite Frage: was soll der alberne Angriff? Hatte dich eigentlich als sachlichen User in Erinnerung ...
Hi Erinnert mich irgend wie an QBasic gegen QuickBasic. Wer hat von den beiden gewonnen? MfG Spess
ThomasW schrieb: > was soll der alberne Angriff? Du meinst: ThomasW schrieb: > was für ein Quark! Wer so desinformationsverbreitend auf (meinen) Beitrag antwortet, darf sich nicht wundern wenn jemand die Fakten zur Richtigstellung als Antwort postet (Dank an Sheeva). Wenn dich Fakten stören: kritisiere nicht den Überbringer der Nachricht, arbeite lieber an deinem (Un)Wissen.
Angehängte Dateien:
-
Bildschirmfoto9.png
68 KB
小さな猫の女の子 schrieb: (Frage zu PHP auf µC) Also PHP gibt es vermutlich nicht für Mikrocontroller. Leider hast du nicht gesagt, welche Eigenschaft von PHP für dich wichtig ist. Falls es dir darum geht, Programmcode in HTML Dateien einzubetten: Das würde ich auf den Client auslagern. Der Mikro-Webserver könnte diese von einer SD Karte aus an den Browser liefern. In der Seite befindet sich Javascript (statt PHP), welche dynamische Inhalte per AJAX Request nachlädt. Der Code auf dem Mikrocontroller könnte sich dann auf diese kleinen Datenschnipsel beschränken. Das können wahlweise HTML Fragmente sein, oder etwas Datenstrukturen in JSON, die dann vom Javascript geparst und gerendert werden. Eventuell magst du dir mal meinen embedded Webserver anschauen http://stefanfrings.de/net_io/index.html, von dem der obige Screenshot kommt. Die HTML Datei enthält Platzhalter, welche während des Auslieferns der Seite vom Server (also dem µC) durch ein generiertes Textfragment ersetzt wird. In dem Seitenquelltext rufen die Platzhalter "%! name" jeweils eine C Funktion auf und "%!: name" inkludiert eine statische HTML Datei (da ist auch das Navigationsmenü drin). Das Formular in der Seite ruft eine weitere C Funktion über AJAX (Javascript, HTTP Request) auf und fügt die Response in die Seite ein. Damit hast du zwei Methoden, die auf Mikrocontrollern in dieser Größenordnung (mit weniger als 100kB RAM) realistisch umsetzbar sind. Das ganze ist bei weiten mich so leistungsfähig wie PHP.
Hallo Stefan ⛄ F. , die Frage wurde an mich gestellt und ich konnte diese zu dem Zeitpunkt nicht beantworten, deswegen hatte ich die hier gestellt. Ich kenne mich mit PHP nicht aus und deshalb kann ich diese Frage Stefan ⛄ F. schrieb: > welche Eigenschaft von PHP für dich wichtig ist. nicht beantworten. Deshalb wollte ich es nur allgemein wissen, ob es möglich wäre und darauf wurde schon öfters die gleiche Antwort gegeben. Das was du danach geschrieben hast, ist auch momentan der Stand der Dinge wie es bei uns funktioniert. Trotzdem danke ich dir für die Antwort und allen anderen auch =^.^= Vielleicht könnte ein Mod diesen Thread hier schließen, da dazu alles gesagt worden ist, zumindest meiner Ansicht nach.
MaWin schrieb: > Wenn dich Fakten stören: kritisiere nicht den Überbringer der Nachricht Welche Fakten meinst Du - das mit den Mausschubsern oder das Märchen, dass PHP immer sämtliche verfügbare Extensions im Bauch haben muss? Okay, also Fakten: warum ist das Standardpaket von PHP so fett? Nicht weil das zwingend so sein muss. Sondern weil da alles reingepackt wird, was der übliche User im Webumfeld so nutzt. Sieht man gut an der Liste die weiter oben gepostet wurde. Da waren nur bei PHP libssl, libxml und ähnliche vorhanden. Eben weil das bei der üblichen Verwendung Sinn macht. Aber jedem steht frei sich seine PHP Engine zu bauen. Mit nur den Libs, die man wirklich braucht. Das ist wirklich simpel, dazu braucht es kein Spezialwissen. Deshalb ist die Aussage, dass PHP zu umfangreich sei, eben Halbwissen. Als würde jemand behaupten Linux wäre nicht für den Serverbetrieb geeignet, weil KDE so fett sei.
NodeJS wäre ja eine Idee auf dem Mikrocontroller wenn man sich schon mit Webseitenprogrammierung auskennt: https://www.neonious.com/ Sheeva P. schrieb: > Nicht unbedingt. ;-) Caching? :-)
ThomasW schrieb: > Aber jedem steht frei sich seine PHP Engine zu bauen. > Mit nur den Libs, die man wirklich braucht. > Deshalb ist die Aussage, dass PHP zu umfangreich sei, > eben Halbwissen. (usw und so fort) Damit suggerierst du, dass es eine realistische Chance gäbe, PHP auf gewöhnlichen Mikrocontrollern zu verwenden. Also auch ohne Betriebssystem, ohne Datenbank und üblicherweise auch ohne Dateisystem. Wir reden hier von Chips mit weit unter 100kB RAM! Da kommt man mit deiner Methode gar nicht weiter.
Philipp K. schrieb: > NodeJS wäre ja eine Idee auf dem Mikrocontroller wenn man sich schon mit > Webseitenprogrammierung auskennt Es wird immer absurder. Hast du schon einen Javascript Interpreter auf einem Mikrocontroller gesehen? Ich meine nicht einen in der Größenordnung vom Raspberry Pi oder ESP32, sondern etwas in Richtung ATmega328 oder meinetwegen auch einen Boliden wie den STM32F4.
Stefan ⛄ F. schrieb: > Es wird immer absurder. So ist es halt bei den Mausschubsern. Keine Grundlagen, daher muss alles immer komplizierter werden.
Stefan ⛄ F. schrieb: > Damit suggerierst du, dass es eine realistische Chance gäbe, PHP auf > gewöhnlichen Mikrocontrollern zu verwenden. Also auch ohne > Betriebssystem, ohne Datenbank und üblicherweise auch ohne Dateisystem. > Wir reden hier von Chips mit weit unter 100kB RAM! > Da kommt man mit deiner Methode gar nicht weiter. War nicht meine Absicht. Denn natürlich haste Recht, das das Quatsch ist! Auf nem Mikrokontroller hat ne Skriptsprache mMn. nichts verloren. Deshalb hab ich für den konkreten Fall hier, weiter oben, auch einen anderen Weg skizziert. In der der uC nur eine simple RESTful-API anbietet. Mit ein bisschen Arbeit bekommt man sogar ne HTML Seite hin, in der das notwendige JS eingebettet ist. Dazu braucht es dann vermutlich auch externen Speicher (ne SD-KARTE zum Beispiel). Aber natürlich ist das weit entfernt von: ich schiebe ein fertiges Projekt mal eben auf nen Mikrokontroller.
> Es wird immer absurder. Hast du schon einen Javascript Interpreter auf > einem Mikrocontroller gesehen? Auch (viele) Mikrocontroller können riesige Mengen an (ext.)MEM ansprechen. Frage nur, ob sowas Sinn machen würde.
Stefan ⛄ F. schrieb: > Es wird immer absurder. Na wenn du meinst, ich hatte ja oben schon geschrieben das es NodeJS zwar für Mikrocontroller gibt aber selbst nicht kenne.. als ich dann das verlinkte Projekt "LowJS" gesehen habe fand ich das eigentlich keine schlechte Idee wenn man Javascript schon beherrscht. Selbst würde ich es nicht nutzen, wollte dies aber mal aufzeigen.
MCUA schrieb: > Auch (viele) Mikrocontroller können riesige Mengen an (ext.)MEM > ansprechen. Frage nur, ob sowas Sinn machen würde. Man kann auch auf einem Drucker Doom spielen. Fehlt "nur" noch jemand, der einem den ganzen Kram portiert. Nnicht Doom, das hat tatsächlich schon jemand gemacht, sondern das PHP und seine Voraussetzungen meine ich. Ein Klacks ist das, alles ganz easy. Lass die Maker mal machen.
Philipp K. schrieb: > LowJS Das läuft auf einem ESP32 Modul und belegt 3 Megabyte Flash! Das ist schon kein gewöhnlicher Mikrocontroller mehr sondern so ziemlich der größte denn es meines Wissens nach in bezahlbar gibt. Leider hat sich der TO nicht dazu geäußert, an welche Hardware er konkret dachte.
> Man kann auch zu Fuß nach Singapur reisen
Statt der Zusatz-Kleiderkosten kann man Flash kaufen (wenn man will)
ThomasW schrieb: > Aber jedem steht frei sich seine PHP Engine zu bauen. Mit nur den Libs, > die man wirklich braucht. PHP ohne Libs ist ziemlich witzlos, das ist ja der Nutzen von PHP gegenüber shell-Skripten, und die meisten Libs sind ohne Betriebssystem nicht einsetzbar.
小さな猫の女の子 schrieb: > wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann, > also zum Beispiel auf einen AVR oder STM, also der Mikrocontroller > ist gleichzeitig der Server Ein großer STM32 kann, mit genug externem RAM ausgestattet, Linux ausführen. Und wenn man ein Linux hat, sind auch Webserver und PHP theoretisch möglich. Sinnvoll ist das in keinem Fall. ThomasW schrieb: > jaja, die ganzen Mausschubser, die das gesamte Backend > von Facebook geschrieben haben ... was für ein Quark! Erstens läuft das Backend von Facebook nicht auf Mikrocontrollern, sondern echt dicken Servern und zweitens läuft das Backend von Facebook auch nicht mit dem PHP-Code. Der wird nämlich erst zu C++ transformiert und compiliert, bevor er ausgeführt wird. So ein Ansatz ist mit Mikrocontrollern übrigens auch möglich, weil man dann auf den eigentlichen PHP-Interpreter verzichten kann. Für den TO allerdings vermutlich trotzdem ungeeignet.
S. R. schrieb: > Erstens läuft das Backend von Facebook nicht auf Mikrocontrollern, > sondern echt dicken Servern und zweitens läuft das Backend von Facebook > auch nicht mit dem PHP-Code. Der wird nämlich erst zu C++ transformiert > und compiliert, bevor er ausgeführt wird. Das habe ich beides nie behauptet (meine Aussage war, dass der Code in PHP geschrieben ist). Einfach mal lesen was ich tatsächlich geschrieben habe ... aber das betrifft nicht nur dich ... schönen Sonntag noch!
Du hast Facebook als Beispiel genutzt, um damit die Aussage zu widerlegen, dass PHP sinnvollerweise eher größere Prozessoren mit ordentlichem Betriebssystem (also mindestens Raspberry Pi-Größe) braucht. Und damit zweimal ins Klo gegriffen, denn (a) nutzt Facebook keine kleinen Prozessoren und (b) führt Facebook den PHP-Code nichtmal aus.
Jetzt werden hier auch noch die PHP Basics weit vom Thema entfernt diskutiert.. Leute das steht in jedem "PHP für Anfänger" Buch im Vorwort. Man kann das ganze auch in SQL Prozeduren auslagern und nur noch Querys ausführen. Duck
Philipp K. schrieb: > Man kann das ganze auch in SQL Prozeduren auslagern und nur noch Querys > ausführen. Da würde ich dann doch Nägel mit Köpfen machen und den Server auf dem µC in PL/SQL schreiben.
> Du hast Facebook als Beispiel genutzt, um damit die Aussage zu > widerlegen, dass PHP sinnvollerweise eher größere Eine CPU weiss weder was von C noch von PHP.
ThomasW schrieb: > Sheeva P. schrieb: >> Wissende sehen: PHP benötigt leider immer noch viel mehr Libraries als >> andere Skriptsprachen. Ich persönlich habe da so eine Idee, woran das >> liegt, aber als offensichtlicher PHP-Könner kannst Du mir das sicher >> besser begründen. ;-) > > Benötigt PHP die wirklich, oder wurden die vorm Compilieren ausgewählt? > Schau dir mal die ganzen Schalter im configure an! Nunja, bei PHP sind ja viele Dinge bereits im Sprachumfang enthalten, für die man anderswo erstmal dynamische Bibliotheken laden muß. PCRE, XML, SSL, Crypto, lzma... wenn ich auf das PHP 7.2-Binary auf meinem Kubuntu 18.04.5 LTS ein ldd(1) loslasse, spuckt er 19 Libraries aus, bei Python3 und Ruby2.5 sind es dagegen lediglich 9. Ich vermute, daß das Spätfolgen des Designfehlers früherer PHP-Versionen sind, die keine Namensräume kannten, und deswegen alles in den globalen Namensraum eingebaut hatten. Dabei konnte man schon früher dynamische Libraries einbinden, etwa aus dem PECL, aber das zu Ladende wurde da über die php.ini konfiguriert und war dann zur Laufzeit immer geladen und vorhanden. Wobei der Designfehler ja mittlerweile zum Glück behoben wurde, und PHP kann jetzt endlich auch Namensräume -- aber trotzdem ist es natürlich absolut verständlich, daß die PHP-Entwickler schon wegen ihrer Abwärtskompatibilität keine (oder jedenfalls so wenig wie möglich) Funktionen aus dem globalen Namensraum entfernen möchten, weil das zu viel existierenden Code zerbrechen und einen Sturm der Entrüstung auslösen würde... > Und zweite Frage: was soll der alberne Angriff? Wir kommst Du darauf, daß das ein Angriff gewesen sein sollte? Das war vollkommen ernst gemeint: offensichtlich benutzt Du aktiv PHP und kennst Dich damit vermutlich deutlich besser aus als ich, denn ich habe damit nur vor knapp zwanzig Jahren eine Serververwaltungssoftware repariert und auf PHP4 portiert, und danach ein Framework mit dem OR-Mapper Doctrine -- zu dessen PostgreSQL-Zeitfunktionen ich seinerzeit einige dutzend Zeilen beigesteuert habe -- für PHP5 entwickelt.
小さな猫の女の子 schrieb: > die Frage wurde an mich gestellt und ich konnte diese zu dem Zeitpunkt > nicht beantworten, deswegen hatte ich die hier gestellt. > > Ich kenne mich mit PHP nicht aus und deshalb kann ich diese Frage > > Stefan ⛄ F. schrieb: >> welche Eigenschaft von PHP für dich wichtig ist. > > nicht beantworten. Hallo, nunja... für manche Mikrocontroller gibt es Micropython, das im Prinzip eine stark abgespeckte Minimalversion von Python3 ist -- aber seinerseits auch schon ein bisschen "Dampf unter der Haube" braucht, also meines Wissens mindestens 256k Flash, 16k RAM, und einen 32-Bitter (man korrigiere mich, wenn das nicht stimmt). Möglicherweise, eventuell und vielleicht ließe sich auch ein PHP-Interpreter in einer ähnlichen Weise abspecken und mit ähnlichen Minimalanforderungen zum Laufen bringen, dazu kann ich keine qualifizierte Aussage treffen. Aber das wäre zweifellos ein neues und ähnlich umfangreiches Projekt wie Micropython... ich glaube, da wäre es einfacher, auf einen RasPi oder einen anderen betriebssystemfähigen SBC zu gehen. YMMV! ;-)
Philipp K. schrieb: > NodeJS wäre ja eine Idee auf dem Mikrocontroller wenn man sich schon mit > Webseitenprogrammierung auskennt: https://www.neonious.com/ > > Sheeva P. schrieb: >> Nicht unbedingt. ;-) > > Caching? :-) Jaein... es gibt Compiler für PHP, zum Beispiel HipHop von Facebook und phc. Damit kann man PHP-Code in $Etwas kompilieren -- aber ich weiß nicht, in was. Für Python beispielsweise gibt es verschiedene Möglichkeiten: man kann Python in ausführbaren (und ggf. optimierten, aber der Optimizer macht wohl nicht allzu viel) Bytecode übersetzen, das kann Python schon in seiner Standarddistribution. Man kann es aber beispielsweise mit nuitka in C trans- und das dann in nativen Code kompilieren. Zudem gibt es dazwischen noch eine Reihe weiterer Möglichkeiten wie etwa py2exe, das aber im Wesentlichen nicht com- oder transpiliert, sondern lediglich den vorhandenen Python-Interpreter und das angegebene Programm und seinen Libraries in ein einzelnes Standalone-Binary verpackt, oder Numba, das darauf spezialisiert ist, mathematische Berechnungen in nativen Code zu übersetzen. Ob es sowas auch für PHP gibt, können vielleicht die PHP-Spezialisten hier sagen.
> Für Python beispielsweise gibt es verschiedene..
Einrücktiefe als Syntaxbestandteil (!)
> Wobei der Designfehler ja mittlerweile zum Glück behoben > wurde, und PHP kann jetzt endlich auch Namensräume .. Und dafür hat es Jahrzehnte gebraucht?
ThomasW schrieb: > Stefan ⛄ F. schrieb: >> Damit suggerierst du, dass es eine realistische Chance gäbe, PHP auf >> gewöhnlichen Mikrocontrollern zu verwenden. Also auch ohne >> Betriebssystem, ohne Datenbank und üblicherweise auch ohne Dateisystem. >> Wir reden hier von Chips mit weit unter 100kB RAM! >> Da kommt man mit deiner Methode gar nicht weiter. > > War nicht meine Absicht. Denn natürlich haste Recht, das das Quatsch > ist! Auf nem Mikrokontroller hat ne Skriptsprache mMn. nichts verloren. Das wiederum ist, bitte entschuldige, meiner Meinung nach -- in dieser kategorischen Rigorosität -- Quatsch. Im Vergleich mit kompilierten Sprachen haben Skriptsprachen spezifische Vorzüge und spezifische Nachteile. Der wesentliche Nachteil ist wohl meistens, daß sie deutlich umfangreichere Ressourcen zur Laufzeit benötigen (mal ganz allgemein gesprochen). Dem gegenüber stehen allerdings auch bestimmte Vorzüge, und der wichtigste davon ist wohl, daß Skriptsprachen (ebenso allgemein gesprochen) Entwicklungszeit sparen. Das entkoppelt die Frage, welcher Sprachtyp für ein bestimmtes Projekt ideal ist, nun allerdings weitestgehend von den technischen Aspekten und macht sie zu einer primär ökonomischen Frage. Dabei hängt es im Wesentlichen von den Anforderungen ab, wie die ökonomische Frage zu bewerten ist. Läuft der Code nur auf wenigen Geräten? Kann der Code auf den Geräten einfach aktualisiert werden? Werden viele Änderungen am Code pro Woche / Monat / Jahr erwartet? Wer mehrere dieser Fragen mit "Ja" beantwortet, ist womöglich mit leistungsfähigerer Hardware und einer Skriptsprache besser bedient. Gibt es harte oder weiche Echtzeitanforderungen? Soll der Code auf vielen Geräten laufen? Ist es schwierig, den Code zu aktualisieren? Soll der Code nur selten geändert werden? In solchen Fällen ist eine kompilierte Sprache vermutlich eine bessere Wahl.
Philipp K. schrieb: > Man kann das ganze auch in SQL Prozeduren auslagern und nur noch Querys > ausführen. Das habe ich aus Spaßesgründen vor vielen Jahren mal ausprobiert, und es hat prima funktioniert -- aber es war das Gegenteil von performant, und beim Entwickeln böse Schmerzen im Gesäß. (Nebenbei: auch OpenLDAP als Datenbackend war nicht so der Hit, aber demnächst möchte ich es gerne mal mit Elasticsearch ausprobieren...) ;-)
Sheeva P. schrieb: > aber ich weiß > nicht, in was. soweit ich weiß packt das nur das precompiled Binary wie beim Caching (oder wie auch immer) mit allen abhängigkeiten in ein Paket... bzw HipHop war nur ein Ansatz der nicht weiterverfolgt wurde. Wie bei den MeinJavaTool.exe Tricks, da wird zum Beispiel ein abgespecktes auf die abhängigkeiten ausgelegtes JRE mit eingepackt... Es gibt auch Programme die holen schon die größe des Fensters und das Hauptmenü aus der SQL DB, alles andere ist dann in der DB als Prozedur.. Funktioniert, benötigt nur einen vernünftigen Server. Da wäre wohl REST/JSON am besten, direkt als SQL Bridge zur MCU. So, ich öffne diesen Thread erst wieder wenn der Gesperrt ist, dann lese ich mit einer Tüte Popcorn weiter :D
MCUA schrieb: >> Für Python beispielsweise gibt es verschiedene.. > Einrücktiefe als Syntaxbestandteil (!) Ja, und? Schau, das hat mich, zugegeben, zumindest am Anfang auch sehr abgeschreckt. Aber dann habe ich festgestellt: viele Leute, die ich für ausgesprochen kompetent halte, haben offensichtlich keine Probleme damit und bieten entweder ein eingebettetes Python oder zumindest eine Python-API an. Open- und LibreOffice, zum Beispiel. KDE. Mercurial, Blender, Cinema 4D, The GIMP, Boost. Und Unternehmen, von Goldman-Sachs, Facebook, Twitter, Google, Ubuntu, SuSE, RedHat, sogar Microsoft... hm. Dazu kamen noch einige Freunde vom örtlichen Linux-Stammtisch, von denen einige hellauf begeistert und andere zumindest nicht gänzlich abgeneigt waren... Da wollte ich als C-, C++- und Perl-Entwickler, der ich zu der Zeit im Wesentlichen war, einfach mal wissen, was es damit auf sich hat. Also habe ich mal ein paar Zeilen Programmcode aus einem Tutorial kopiert, ein bisschen damit herumgespielt, und sehr schnell festgestellt: diese obskure Zeug mit den Einrückungen führt einerseits zu sehr kompaktem und andererseits zu sehr lesbarem Code (wobei C, C++ und Perl da ja nun auch nicht die besten Beispiele waren und sind...), die Objektorientierung war sehr schön und einfach, ich konnte viel schneller entwickeln als in C++ und Perl, trotz großer (mehr als zehn Jahre) Erfahrung in den beiden Sprachen. Und deutlich performanter als Perl war es obendrein, hatte viel mehr nützliche Standardbibliotheken dabei... ich war (und bin es bis heute) von Python einfach nur begeistert. Das ist jetzt... omg, sicher weit über zehn Jahre her, und heute hat sich Python zu einer der beliebtesten Skriptsprachen der Welt entwickelt. Und immer noch streitet die Welt, ob das nun TROTZ oder WEGEN dieser Eigenschaft mit dem syntaxrelevanten Whitespace ist. Tatsache ist: Python ist so einfach, daß es in Großbritannien sogar an Grundschulen als erste Sprache gelehrt wird, und gleichzeitig so mächtig, daß es auch bei den DataScience-Numbercrunchern, GUI-, Spiele- und anderen Bereichen, in denen es um hohe Performanz geht, entweder sehr beliebt oder sogar das beliebteste Werkzeug überhaupt ist. Systemadministratoren schätzen es nicht nur wegen Ansible, Analysten wegen Numpy und Pandas, Webentwickler wegen Zope, Plone, Django, und Flask, und Datenbankadministratoren, weil sogar Stored Procedures in PostgreSQL damit geschrieben werden können. Du kannst es jetzt machen, wie ich das eine Weile lang gemacht habe, und auf Deinen Vorurteilen bestehen. Ich möchte nicht missionieren -- aber eine Sprache, die man nicht kennt, mit der man keinerlei Erfahrung hat, nur wegen so einer lächerlichen und unwichtigen Äußerlichkeit pauschal und rundheraus abzulehnen... das erscheint mir persönlich nicht besonders klug. YMMV. ;-)
MCUA schrieb: >> Wobei der Designfehler ja mittlerweile zum Glück behoben >> wurde, und PHP kann jetzt endlich auch Namensräume .. > Und dafür hat es Jahrzehnte gebraucht? Ja, hat es. Einerseits weil PHP ja zunächst nur als "Personal Home Page Tools" von Rasmus Lerdorf geplant war, deswegen hatten die Entwickler des Projekts gewisse... Schwierigkeiten mit der Entscheidung, ob es nun eine vollwertige Allroundsprache werden, oder doch nur eine einfache Sprache zum Coden einfacher Interaktion auf Websites, also etwas wie empperl oder eine Art SSI auf Steroiden werden sollte. Aus... berufenem Mund habe ich auch das Gerücht vernommen, daß einige Entwickler des PHP-Interpreters wohl zwischenzeitlich das Projekt verlassen hatten, und es deswegen im Projekt niemanden mehr gegeben haben soll, der den Code des Parsers verstehen konnte. Keine Ahnung, ob das stimmt... "\(".)/" Wie dem auch sei: ich habe mit PHP gearbeitet und halte es immer noch für keine gute Idee, die krude "Stringverarbeitung" von C mit der verkopften Objektorientierung von Java in etwas einzubauen, das vornehmlich eine gedopte Template-Engine ist. Aber man kann gutes Geld damit verdienen, das ist doch immerhin etwas! ;-)
>> Einrücktiefe als Syntaxbestandteil (!) > Ja, und? Habe damit auch programmieren (müssen). Einmal Code an andere Stelle verschoben, völlig andere Bedeutung, keine Fehlermeldung. Bescheuert! Das hat sich ein Id??? ausgedacht.
Philipp K. schrieb: > Sheeva P. schrieb: >> aber ich weiß >> nicht, in was. > > soweit ich weiß packt das nur das precompiled Binary wie beim Caching > (oder wie auch immer) mit allen abhängigkeiten in ein Paket... bzw > HipHop war nur ein Ansatz der nicht weiterverfolgt wurde. Wie gesagt, das weiß ich nicht. Für mich war PHP zweimal in meinem Leben ein Tool, um damit Geld zu verdienen, und wegen meiner Erfahrungen mit Perl war ich auch ganz gut damit (das sollen andere beurteilen... aber sie haben bezahlt). Trotzdem habe ich natürlich versucht, ein gutes Mitglied der Community zu sein, und das, was ich für bestimmte Frameworks wie Doctrine entwickelt habe (...mit der Erlaubnis meines damaligen Auftraggebers) an die Community zurück zu geben. > Wie bei den MeinJavaTool.exe Tricks, da wird zum Beispiel ein > abgespecktes auf die abhängigkeiten ausgelegtes JRE mit eingepackt... Naja, das ist ja etwas Ähnliches wie das, was py2exe macht, und -- um ehrlich zu sein -- löst sowas möglicherweise sehr viele Probleme beim Deployment und beim Lifecycle-Management. Und ich weiß, für den Entwickler ist so etwas weitgehend irrelevant -- aber für einen Admin, der im Zweifelsfalle erstmal Pakete bauen, Abhängigkeitskonfigurationen, Paket- oder Docker-Repositories aufsetzen muß... Bei Java hat mich auch nie die Paketierung gestört, es waren immer vielmehr die Web Application Server. Letztes Jahr gab es für eine Webapplikation meines Arbeitgebers ausschließlich kommerzielle WAS wie JBoss und Websphere -- Wildfly war zu weit und hatte Memory Leaks, Tomcat und Glassfish waren nicht weit genug und für produktive Nutzung ohnehin ungeeignet, weil es keine Sicherheitspatches gab. Und dann kam auch noch diese Sache mit Oracles neuen Lizenzbestimmungen dazu... > Es gibt auch Programme die holen schon die größe des Fensters und das > Hauptmenü aus der SQL DB, alles andere ist dann in der DB als Prozedur.. > Funktioniert, benötigt nur einen vernünftigen Server. Da wäre wohl > REST/JSON am besten, direkt als SQL Bridge zur MCU. Wie gesagt: BTDT. Macht aber halt keinen Spaß, ne... ;-)
MCUA schrieb: >>> Einrücktiefe als Syntaxbestandteil (!) >> Ja, und? > Habe damit auch programmieren (müssen). > Einmal Code an andere Stelle verschoben, völlig andere Bedeutung, keine > Fehlermeldung. > Bescheuert! Das hat sich ein Id??? ausgedacht. Merkwürdig, so etwas habe ich noch nie erlebt. Kann es -- ich vermute nur -- daran liegen, daß Du es "(müssen)" mußtest? Nebenbei bemerkt, gab und gibt es an so ziemlich jeder Programmiersprache, die ich kann oder mal gekonnt habe, ein paar Sachen, die mich manchmal behindert, gestört, oder geärgert haben. Für mich (!) ist Python das mit Abstand geringste aller Übel, wenngleich Du ebenso frei wie herzlich eingeladen bist, das anders zu sehen. ;-) Es ist halt nur so, daß persönliche Vorlieben, nunja, persönlich sind, und keine sonderlich guten Argumente darstellen. ;-)
MCUA schrieb: >> Für Python beispielsweise gibt es verschiedene.. > Einrücktiefe als Syntaxbestandteil (!) Nicht nur das, auch Leerzeilen gehören zur Syntax. Völlig gaga. Und die Performance ist selbst auf einem Quad Core PC eher traurig.
Sheeva P. schrieb: > Da wollte ich als C-, C++- und Perl-Entwickler, der ich zu der Zeit im > Wesentlichen war, einfach mal wissen, was es damit auf sich hat. Soweit war unsere Firma auch mal. Man hat sich das schöne bunte Odoo angeschaut. Meine Aufgabe war, ein paar CRM Module von Odoo zu erweitern. Am Ende wurden wir alle sehr enttäuscht, vor allem von der Performance. Das Programm taugt nur zur Demonstration. Sobald auch nur 5 Leute damit ernsthaft einen Monat arbeiten, wird es zur Schnecke.
Bei Python den Einrückzwang bzw. Bedeutungsänderung anhand der Einrückung finde ich persönlich nicht schlimm, sondern eher gut. Zumal man sich daran doch gut daran gewöhnt. Man darf natürlich aber auch nicht mit der Einstellung rangehen, Python ist blöd, der Einrückzwang ist blöd und dies und jenes, dann kann man mit Python natürlich nicht so gut umgehen.
> Einrücktiefe als Syntaxbestandteil (!)
Wegen dem fehlenden Abschlusszeichen steigt die Fehleranfälligkeit mit
zunehmender Einrücktiefe! Und man kriegt (insbes. beim Umstrukturieren)
keine Fehlermeldung! (was nicht da ist kann man nicht beanstanden)
Sowas bezeichne ich als syntakt. Schwachsinn.
> Tatsache ist: Python ist so einfach, daß es in Großbritannien sogar an > Grundschulen als erste Sprache gelehrt wird, Lernt man dort auch Mikroprozessortechnik?
> Und die Performance ist selbst auf einem Quad Core PC eher traurig.
Würde sagen, schnarchlangsam.
Python hat nichts, was man Anders nicht machen könnte.
MCUA schrieb: > Python hat nichts, was man Anders nicht machen könnte. Ich betrachte es als nachfolger von Perl. Wobei Perl inzwischen in der Bedeutungslosigkeit verschwunden ist.
Stefan ⛄ F. schrieb: > Sheeva P. schrieb: >> Da wollte ich als C-, C++- und Perl-Entwickler, der ich zu der Zeit im >> Wesentlichen war, einfach mal wissen, was es damit auf sich hat. > > Soweit war unsere Firma auch mal. Man hat sich das schöne bunte Odoo > angeschaut. Meine Aufgabe war, ein paar CRM Module von Odoo zu > erweitern. Am Ende wurden wir alle sehr enttäuscht, vor allem von der > Performance. Das Programm taugt nur zur Demonstration. Sobald auch nur 5 > Leute damit ernsthaft einen Monat arbeiten, wird es zur Schnecke. Seltsam, ich kenne drei Unternehmen mit jeweils mehr als 100 MA, die odoo verwenden und mit der Performance absolut zufrieden sind. Ein Unternehmen, das auf odoo as a Service speziaisiert ist, hostet laut deren Angaben etwa 3.000 odoo-Instanzen auf einem Xeon mit sechs Kernen, HT und 32 GB RAM, und auch das soll sehr rund laufen. Deswegen frage ich mich gerade, ob Ihr vielleicht irgendwas übersehen habt? Kannst Du mir vielleicht etwas über Euer Setup erzählen, zum Beispiel: welches Datenbank-Backend habt Ihr benutzt, wie war es konfiguriert, und wie sah das Frontend aus? Besonders die Sache mit der DB würde mich sehr interessieren, zumal ich weiß, daß zB. PostgreSQL standardmäßig mit EXTREM konservativen Einstellungen ausgeliefert wird und auf moderner Hardware nur dann performant läuft, wenn man diese Einstellungen entsprechend verändert. Ansonsten ist Python mit seinem Standard-Interpreter natürlich nicht besonders performant, wenn man es mit C oder C++ vergleicht. Aber so lahm, wie Du tust, ist es nach meinen Erfahrungen auch nicht, wenn der Entwickler weiß, was er tut. Aber das muß er ja überall, nicht wahr?
Stefan ⛄ F. schrieb: > MCUA schrieb: >>> Für Python beispielsweise gibt es verschiedene.. >> Einrücktiefe als Syntaxbestandteil (!) > > Nicht nur das, auch Leerzeilen gehören zur Syntax. Das stimmt nicht, wie kommst Du darauf?
MCUA schrieb: >> Und die Performance ist selbst auf einem Quad Core PC eher traurig. > Würde sagen, schnarchlangsam. Genau... deswegen ist Python ja auch gerade in den Anwendungsbereichen besonders beliebt und verbreitet, wo es um die Verarbeitung von Datenmengen geht, die sich die meisten Mikrocontroller-Entwickler gar nicht mehr vorstellen können: im Distributed Computing und im Machine Learning gibt es kein ernstzunehmendes Framework, das sich den Luxus leisten könnte, keine Python-Schnittstellen zu haben, und im Bereich der Data Science ist Python sogar beliebter und verbreiteter als die auf dieses Umfeld besonders spezialisierte Sprache R. Übrigens: mit speziell konstruierten Beispielen performt der JIT-Compiler Pypy sogar besser als die äquivalenten Beispiele in C, siehe [1] und [2]. Ich persönlich würde mal vermuten: daß Python bei Euch nicht performt, liegt nicht an Python. ;-) [1] https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html [2] https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html > Python hat nichts, was man Anders nicht machen könnte. Ach, wißt Ihr, ich weiß ja nicht, warum Ihr so verbittert und frustriert seit. Fakt ist: Auch Eure Unkenrufe konnten nicht verhindern, daß Python zur beliebtesten und verbreitetsten Skriptsprache der Welt geworden ist, und ich würde jederzeit eine schöne Flasche Scotch darauf wetten, daß Euer Gebashe auch in Zukunft nichts daran ändern wird. Aber in diesem Punkt hast Du Recht: man könnte das mit Python und C einfach lassen, und alles einfach in Assembler schreiben. Das Ergebnis ist dann bestimmt extremst performant... also, wenn Ihr zu Euren Lebzeiten mal zu einem Ergebnis für Aufgaben jenseits von "Hello, world" kommt... und ob Euer Ergebnis dann auch nur halb so stabil und zuverlässig ist wie der Python-Interpreter, bezweifle ich stark. ;-)
Sheeva P. schrieb: > die sich die meisten Mikrocontroller-Entwickler gar > nicht mehr vorstellen können Einleitung: Ich finde es gut, dass du dein Herz für eine Programmiersprache geöffnet hast! Kontra: Nur, das mit den Äpfeln und Birnen.... Weder Python noch PHP sind sonderlich gut für "Mikrocontroller" geeignet. Eher gar nicht.
Sheeva P schrieb >Da wollte ich als C-, C++- und Perl-Entwickler, der ich zu der Zeit im >Wesentlichen war, einfach mal wissen, was es damit auf sich hat. >... >Das ist jetzt... omg, sicher weit über zehn Jahre her, und heute hat >sich Python zu einer der beliebtesten Skriptsprachen der Welt >entwickelt. Und immer noch streitet die Welt, ob das nun TROTZ oder >WEGEN dieser Eigenschaft mit dem syntaxrelevanten Whitespace ist. >Tatsache ist: Python ist so einfach, daß es in Großbritannien sogar an >Grundschulen als erste Sprache gelehrt wird, und gleichzeitig so Diesen Beitrag finde ich zur Diskussion recht passend: https://www.mikrocontroller.net/attachment/487404/lange_nacht_der_programmiersprachen_dlf_ausschnitt.mp3
Arduino Fanboy D. schrieb: > Sheeva P. schrieb: >> die sich die meisten Mikrocontroller-Entwickler gar >> nicht mehr vorstellen können > Einleitung: > Ich finde es gut, dass du dein Herz für eine Programmiersprache geöffnet > hast! Nicht nur für eine, C++ mag ich auch sehr gerne! ;-) > Kontra: > Nur, das mit den Äpfeln und Birnen.... > Weder Python noch PHP sind sonderlich gut für "Mikrocontroller" > geeignet. > Eher gar nicht. Naja, wie ich oben schon geschrieben habe: am Ende ist es eine Frage des konkreten Anwendungsfalls und seiner ökonomischen Betrachtung. Einfach pauschal zu sagen "ist nicht sonderlich gut geeignet für Mikrocontroller" finde ich nicht sehr zielführend; Micropython existiert und soll sich auf größeren Mikrocontrollern wie dem ESP32 und den OpenMV-Kameraboards einiger Beliebtheit erfreuen. De facto streitet dieses Forum aber schon, seit ich hier mitlese, darüber, welche Sprache(n) für die Programmierung von Mikrocontrollern geeignet seien. Es gibt da eine nicht sehr große, dafür aber zeitweilig sehr laute Gemeinde von Entwicklern, für die selbstverständlich und ohne jede Frage nur Assembler in Frage kommt. Eine andere, größere und oft noch viel lautstärkere Gemeinde von Entwicklern vertritt hingegen die Ansicht, daß C das Einzig Wahre (tm) sei. Die beiden Gruppen liefern sich zum Teil sehr erbitterte... "Diskussionen" und hacken dann wieder in schönster Einigkeit auf jenen herum, die -- wie ich -- C++ auch für die Programmierung von Mikrocontrollern bevorzugen. Insofern wundert es mich nun wirklich keinen Bruchteil einer Sekunde lang, daß bei der Erwähnung einer Skriptsprache auf einem Mikrocontrollern genau die "Diskussion" stattfindet, die wir hier sehen. Natürlich muß es für Entwickler, die sich mit so "lesbaren" Konstrukten in Assembler oder C herumschlagen, wie Blasphemie wirken, wenn wir Jungspunde (okay, ich werde im Mai 50) daher kommen und es mit ein paar winzigen Tricks schaffen, unseren Code so lesbar zu schreiben, daß ihn sogar ein Mensch verstehen kann, der noch nie etwas mit Entwicklung zu tun hatte. Insofern verstehe ich den Ärger der Assembler- und C-Freunde sehr gut und natürlich auch, warum so etwas wie eine interpretierte Skriptsprache auf einem Mikrocontroller diesen Menschen wie ein Sakrileg vorkommen muß. Aber auch wenn ich die Wut verstehe, kann ich sie doch nicht als seriöses Argument erkennen. Denn das Zweite, das ich in meiner Zeit als Entwickler gelernt habe, ist: verschiedene Werkzeuge haben spezifische Vor- und Nachteile, und deswegen kommt es immer darauf an, das richtige Werkzeug für einen Anwendungsfall zu wählen. Und sich dabei immer nur auf irgendwelche Leitsätze, Glaubenssätze, oder Dogmen zu verlassen, halte ich ganz persönlich für unseriös und unprofessionell. Übrigens habe ich aus meinem Leben noch ein Drittes mitgenommen, nämlich die drei wichtigsten Leitsätze der Performanceoptimierung: "Premature optimization is the root of all evil" (Donald E. Knuth), "Measure, don't guess" (Kirk Pepperdine) und "Make it work, make it right, make it fast" (Kent Beck), das Letztere ist bekannt geworden als ein Teil des "UNIX-Weges" [1]. Und aus den besagten "Diskussionen" im Forum hier habe ich noch etwas Schönes gelernt: "für nichtgenutzte Ressourcen gibt es kein Geld zurück". ;-) [1] https://wiki.c2.com/?UnixWay
mchris schrieb: > Diesen Beitrag finde ich zur Diskussion recht passend: > https://www.mikrocontroller.net/attachment/487404/lange_nacht_der_programmiersprachen_dlf_ausschnitt.mp3 Abgesehen von den sachlichen und fachlichen Fehlern des Beitrages habe ich leider nicht verstanden, inwieweit er zur Diskussion paßt. Was, bitte, meinst Du denn?
Sheeva P. schrieb: > De facto streitet dieses Forum aber schon, seit ich hier mitlese, > darüber, welche Sprache(n) für die Programmierung von Mikrocontrollern > geeignet seien. Natürlich! Die Auswahl ist begrenzt, und der Priester Trieb ausufernd. Es bietet sich ASM an, wenn man auf einer Insel wohnen möchte, oder nur zur doof ist, um anständig mit Datentypen hantieren zu können. Klar dann gibts noch C und C++! Aber alles, was darüber hinaus geht(SkriptSprachen), da muss die Hardware schon um (mehrere) Zehnerpotenzen leistungsfähiger sein.
Arduino Fanboy D. schrieb: > Aber alles, was darüber hinaus geht(SkriptSprachen), da muss die > Hardware schon um (mehrere) Zehnerpotenzen leistungsfähiger sein. Als was? Als ein AtTiny13? Klar. Hat das jemand bestritten oder auch nur bezweifelt? Nicht daß ich wüßte, ansonsten möge man mir bitte einen Link geben. Aber daß die Hardware leistungsfähiger sein muß, ist allein für sich doch trotzdem noch kein sachliches Argument. Es sei denn, jemand hätte grundsätzlich etwas gegen leistungsfähigere Hardware. Hast Du das? Wenn ja, warum? ;-) Ich bleibe dabei: es kommt immer auf den konkreten Anwendungsfall an.
Sheeva P. (sheevaplug) >Abgesehen von den sachlichen und fachlichen Fehlern des Beitrages habe >ich leider nicht verstanden, inwieweit er zur Diskussion paßt. Was, >bitte, meinst Du denn? Ich nehme an, du meinst die Anmerkung im Beitrag dass Unix in Sieblassblass geschrieben sei. Das ist mir auch etwas sauer aufgestoßen. Da du Python erwähnt hattest, fand ich den Ausschnitt aus "die langen Nacht der Programmiersprachen" von DLF sehr passend, weil die mit Witz auf den Kampf zwischen den Anhängern verschiedener Programmiersprachen eingehen. In diesem Sinne passt auch "BASIC", dass ja von vielen Programmieren als zu einfach erachtet wurde und sich aber genau deshalb so weit verbreitet hatte. Der Radiobeitrag ist übrigens 3 Stunden lang und ich kann ihn sehr empfehlen. Es geht von den ersten Rechenmaschinen bis zu den modernen Programmiersprachen. Etwas später gibt es sogar ein paar Sätze zu PHP ( ich bin aber gerade zu faul, das zu kopieren ).
Sheeva P. schrieb: > Deswegen frage ich mich gerade, ob Ihr > vielleicht irgendwas übersehen habt? Womöglich hat unsere Projektleitung die hohen Hardwareanforderungen nicht hinnehmen wollen. Wir haben es auf einer VM mit 4 CPU Kernen und 4GB RAM laufen lassen, so wie fast alle anderen Anwendungen auch. Als Datenbank kam PostgreSQL mit der Standardkonfiguration zum Einsatz, lief in der selben VM. Ich glaube dir ja, dass man da einiges noch tunen kann. Aber auch funktional hat das Paket nicht überzeugt. Unser Kunde hätte es genommen, wenn 80% der gewünschten Funktionen schon drin gewesen wären. Aber das war halt nicht der Fall. Am Ende haben sie sich für eine komplett neue Anwendung in Java entschieden (an der arbeitet mein Team seit 1,5 Jahren). Da spielt sicher auch eine Rolle, das sowohl unsere Entwickler als auch die des Kunden sich mit Java EE viel besser auskennen. Python wäre Neuland gewesen. Aber interessantes Neuland, deswegen hatte ich mich darauf eingelassen.
> Weder Python noch PHP sind sonderlich gut für "Mikrocontroller" > geeignet. Stimmt >> Nicht nur das, auch Leerzeilen gehören zur Syntax. >Das stimmt nicht, wie kommst Du darauf? Auch wenn es nicht stimmt, ist es bescheuert. Die (beschriebene) Fehleranfälligkeit ist da! > Aber alles, was darüber hinaus geht(SkriptSprachen), da muss die > Hardware schon um (mehrere) Zehnerpotenzen leistungsfähiger sein. Sagt offensichtl. jemand, der keine MCUs kennt (kennen will). >Es bietet sich ASM an, wenn man auf einer Insel wohnen möchte, oder nur >zu doof ist, um anständig mit Datentypen hantieren zu können. Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein Hochsprachen-Programmierer.
MCUA schrieb: > Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein > Hochsprachen-Programmierer. Die wären?
Stefan ⛄ F. schrieb: > MCUA schrieb: >> Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein >> Hochsprachen-Programmierer. > > Die wären? Kleine Klappe, mittlere Klappe, große Klappe, riesengroße Klappe, exorbitantgroße Klappe, ... :D SCNR.
>> Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein >> Hochsprachen-Programmierer. > Die wären? Alle möglichen, beliebig zusammenbaubar, was so in Hochsprachen nicht möglich ist. > Kleine Klappe, mittlere Klappe, große Klappe, riesengroße Klappe, > exorbitantgroße Klappe, ... :D Dumme Klappe.
MCUA schrieb: > Alle möglichen, beliebig zusammenbaubar, was so in Hochsprachen nicht > möglich ist. So, wie structs in C?
Stefan ⛄ F. schrieb: > Und die Performance [von Python] ist selbst auf einem > Quad Core PC eher traurig. Erstaunlich positiv überrascht war ich vor vielen Jahren von Perl, extrem negativ überrascht von Ruby. Aber Python ist jetzt kein besonderes Beispiel von Langsamkeit. Wenn man damit wirklich große Datenmengen durchnudelt, dann läuft im Hintergrund meist sowieso native code, wo es keine Rolle spielt. Ich vermute daher, dass bei euch nicht "Python" der Grund, zumindest nicht der ausschlaggebende. Mit der Einrückung muss man sich abfinden. Fand ich anfangs auch scheiße, inzwischen nicht mehr. Ist weder gut noch schlecht; andere Sprachen (z.B. Kotlin) haben auch ihre festen Ansichten, mit denen man sich abfinden muss, wenn man sie benutzen will. Ich mag C, aber wer das als ultimativen Maßstab für eine gute Programmiersprache nimmt, sollte sich bitte von Computern fernhalten. MCUA schrieb: >>> Nicht nur das, auch Leerzeilen gehören zur Syntax. >>Das stimmt nicht, wie kommst Du darauf? > Auch wenn es nicht stimmt, ist es bescheuert. > Die (beschriebene) Fehleranfälligkeit ist da! Wenn es nicht stimmt - und es stimmt nicht - dann ist es kein Argument. >>Es bietet sich ASM an, wenn man auf einer Insel wohnen möchte, oder nur >>zu doof ist, um anständig mit Datentypen hantieren zu können. > Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein > Hochsprachen-Programmierer. Du meinst "word"? Also den einen Integer-Typ, den man in ein Register schreiben kann? Weil andere Datentypen gibt es in Assembler nicht. Nur verschiedene Instruktionen, die diesen einen Datentyp überall unterschiedlich auslegen.
mchris schrieb: > Sheeva P. (sheevaplug) >>Abgesehen von den sachlichen und fachlichen Fehlern des Beitrages habe >>ich leider nicht verstanden, inwieweit er zur Diskussion paßt. Was, >>bitte, meinst Du denn? > > Ich nehme an, du meinst die Anmerkung im Beitrag dass Unix in > Sieblassblass geschrieben sei. Das ist mir auch etwas sauer aufgestoßen. Ja, das war einer der Punkte, hinzu kam in dem Zusammenhang auch noch der Einspieler von der Dame, die keine Ahnung von C++ hatte und es deswegen nicht nur abgelehnt, sondern gleich auch ("häßliche Syntax") darauf herumhacken mußte... Ebenso seltsam fand ich die Aussage, BASIC sei als eine Art "PR-Maßnahme" entwickelt worden, dabei ging es doch vielmehr darum, das Arbeitsgerät Computer auch für Menschen zugänglich zu machen, die eben keine studierten Informatiker waren -- ähnlich wie das Arduino-Projekt heute die Mikrocontroller-Elektronik für Menschen zugänglich machen möchte, die keine E-Techniker oder Informatiker sind. Naja, vielleicht habe ich auch einfach den Humor dahinter nicht verstanden... ;-) > Da du Python erwähnt hattest, fand ich den Ausschnitt aus "die langen > Nacht der Programmiersprachen" von DLF sehr passend, weil die mit Witz > auf den Kampf zwischen den Anhängern verschiedener Programmiersprachen > eingehen. In diesem Sinne passt auch "BASIC", dass ja von vielen > Programmieren als zu einfach erachtet wurde und sich aber genau deshalb > so weit verbreitet hatte. Najaaa... als das "originale" BASIC entstand, gab es ja schon andere Sprachen, die strukturierte Programmierung ermöglicht haben, ALGOL zum Beispiel. Da erschien die BASIC-Lösung mit "GOTO", das letzlich Spaghetticode erzwungen hat, nicht schön...
Stefan ⛄ F. schrieb: > Sheeva P. schrieb: >> Deswegen frage ich mich gerade, ob Ihr >> vielleicht irgendwas übersehen habt? > > Womöglich hat unsere Projektleitung die hohen Hardwareanforderungen > nicht hinnehmen wollen. Wir haben es auf einer VM mit 4 CPU Kernen und > 4GB RAM laufen lassen, so wie fast alle anderen Anwendungen auch. Najaaa... mit zwei Kernen und 4 GB RAM wart Ihr da nur knapp über dem Minimum, 2 Kerne und 2 GB RAM werden für 5 Benutzer als Minimum angegeben, empfohlen werden allerdings 8 GB RAM. Und... bitte entschuldige, warum richtet Ihr Euch nach Euren anderen Anwendungen statt an die Empfehlungen des Herstellers? > Als Datenbank kam PostgreSQL mit der Standardkonfiguration zum Einsatz, > lief in der selben VM. Oh, okay... das ist zwar leider sehr beliebt, aber (fast?) immer ein Fehler. Wie gesagt, die Standardkonfiguration von PostgreSQL ist für moderne Maschinen extrem konservativ. Nun, im PostgreSQL-Wiki gibt es eine Reihe von Links zu verschiedenen Guides und Tutorials, wie man PostgreSQL optimieren kann. Wenn man ein PostgreSQL ernsthaft und produktiv nutzen möchte, beginnt das bereits mit der Auswahl von passender Hardware, aber für ein paar Tests einer Applikation wird man das wohl nicht wollen. Nur um ein paar Punkte zu erwähnen: je nach Distribution wird entweder die Standardkonfiguration aus dem PostgreSQL-Repository paketiert oder zumindest eine eigene postgresql.conf ausgeliefert wie bei (K)Ubuntu. Nur um zu zeigen, wie weit die wichtigste Standardeinstellung, nämlich die Größe des Shared Memory (Konfigurationsoption "shared_buffers") von optimierten Einstellungen abweicht: in der Standardkonfiguration des PostgreSQL-Quellcodes steht diese auf 32 Megabyte, unter Ubuntu sind es immerhin 128 MB. Für ein System mit 4 GB RAM würde dieser Wert allerdings idealerweise bei etwa 1 GB stehen. Dazu gibt es allerdings noch einige weitere Möglichkeiten, PostgreSQL Beine zu machen. Bekannt sind Indizes, die Lesezugriffe (SELECT) deutlich beschleunigen können, Schreibzugriffe (INSERT und UPDATE) jedoch etwas verlangsamen und zudem ihrerseits Arbeitsspeicher oder, wenn man es übertrieben hat, sogar Festplattenplatz kosten. Neuere Versionen von PostgreSQL beherrschen dafür allerdings mittlerweile auch Index-Only-Scans, so daß bei SELECTs, die nur indizierte Spalten betreffen, nicht mehr auf die tatsächlichen Tabellen zugegriffen werden muß und die Daten gleich aus dem Index gelesen werden können. Außerdem gibt es (mittlerweile sogar mehrere) Möglichkeiten, Tabellen anhand bestimmter Kriterien zu partitionieren. PostgreSQL beherrscht nämlich etwas, das sich "Vererbung" nennt: Für eine Elterntabelle werden mehrere Kindtabellen angelegt und eingesetzte Daten anhand des Partitionierungskriteriums (zum Beispiel Tag oder Monat, das macht dann auch das Housekeeping einfacher, oder auch anhand eines Feldes oder eines HAshwerts) auf diese Kindtabellen verteilt. Die Operationen werden dann nur auf der Elterntabelle ausgeführt und an die Kinder "verteilt"; neuere PostgreSQL-Versionen können die Zugriffe auf die Kindtabellen dabei auch parallelisieren. Ein weiterer Vorteil der Partitionierung ist, daß es keinen riesengroßen Index (der eventuell nicht mehr in den Arbeitsspeicher passen würde) für die Elterntabelle gibt, sondern viele kleine Indizes für die Kindtabellen -- und da PostgreSQL intern Statistiken über die Indexnutzung führt, können seltener genutzte Indizes der Kinder auf die Festplatte ausgelagert und die für oft genutzte Kindtabellen im Arbeitsspeicher gehalten werden -- das funktioniert natürlich am Besten für ein zeitbasiertes Partitionierungskriterium, was zudem auch noch das Housekeeping der Datenbank vereinfacht: alte, nicht mehr genutzte Kindtabellen können dann schnell und einfach gelöscht werden. Ganz grundsätzlich bietet es sich unter PostgreSQL an, zu langsame Queries zu loggen ("log_min_duration_statement") oder in den View "pg_stat_statements" zu schauen. Wer PostgreSQL seriös produktiv betreiben möchte, dem sei allerdings geraten, sein Logging anhand der Vorgaben des PostgreSQL-Loganalalyzers "pgfouine" zu konfigurieren und die Logdateien in regelmäßigen Abständen damit zu analysieren. Dieses Werkzeug liest die Logdatei und erstellt Statistiken bezüglich der verwendeten Queries, ihrer Laufzeiten und der Anzahl ihrer Aufrufe, was wiederum Hinweise darauf liefert, bei welchen Queries womöglich eine sinnvolle Optimierung ansetzt. Deswegen ist natürlich klar, daß dieses Werkzeug nur dann sinnvolle Ergebnisse liefern kann, wenn die analysierten Logdateien unter realen Produktionsbedingungen mit den realen Produktionsdaten entstanden sind. Übrigens: PostgreSQL selbst liefert bereits ein gut konfigurierbares Benchmarkprogramm namens "pgbench" mit aus. Damit kann man den Erfolg von geplanten Optimierungen prüfen, bevor man sie in die Produktion übernimmt. Auch sonst bietet PostgreSQL etliche Möglichkeiten zur Optimierung, von der Konfiguration der Konstanten des Query Planners, das Ein- und Ausschalten von bestimmten Scantypen, bis hin zur Konfiguration der PostgreSQL-internen Statistiksammlungen. Man kann sogar das fsync(2) nach jedem Write oder das Write-Ahead-Log ausschalten (was ich bei einer Applikation wie einem ERP, das auf maximale Datenintegrität angewiesen ist, allerdings nicht empfehlen würde). Aus meiner eigenen Erfahrung kann ich vom Fall eines us-amerikanischen Versicherungskonzerns berichten. Nach Inbetriebnahme unserer Software auf einer ziemlich großen Maschine begann die Applikation zu lahmen, nachdem die Datenbank mit etwa 30 GB Daten beschickt worden war. Nach unseren Performancetuning war die Datenbank zuletzt gute 970 GB groß und hatte keine Performanceprobleme mehr, auf derselben Hardware. Dies nur, um die Größenordnung zu zeigen, die möglich sein können. Auch Python kann man sehr deutlich beschleunigen, zum Beispiel, wenn man nicht den (nicht auf Performance, sondern auf Korrektheit optimierten) Standardinterpreter durch den wesentlich schnelleren Interpreter Pypy mit JIT-Compiler ersetzt. Der wirkt zwar erst nach einiger Zeit, kann die Performance aber um den Faktor drei bis zehn verbessern, je nach konkretem Anwendungsfall. Leider finden sich im Netz allerdings nur Benchmarks für den Standardinterpreter, was der Sprache leider häufig (die Blogosphäre hat ein laaaanges Gedächtnis) den Ruf eingebracht hat, nicht besonders performant zu sein. Neben Pypy gibt allerdings auch den Java-Interpreter Jython, der zudem den großen Vorteil hat, nativ aus Python heraus auf Java-Code zugreifen zu können, sowie den .NET-basierten Interpreter Ironpython, der dasselbe mit dem .NET-Framework beherrscht. Zudem -- nur eine Anregung -- ist es nach meinen Erfahrungen keine so gute Idee, Applikation und Datenbank auf derselben Hardware oder VM laufen zu lassen. Dann konkurrieren die beiden Prozesse im Prinzip um dieselben Ressourcen, die sich aufgrund widerstrebender Ziele leider auch nicht wirklich für eine der beteiligten Anwendungen optimiert konfigurieren lassen. Je nach Umfang des Datenverkehrs zwischen der Webapplikation und dem Datenbank-Backend kann es dabei auch sinnig sein, eine performantere Netzwerkanbindung anstelle von dem üblichen Gigabit Ethernet einzusetzen... aber nicht zum Testen, klar. > Ich glaube dir ja, dass man da einiges noch tunen kann. Aber auch > funktional hat das Paket nicht überzeugt. Unser Kunde hätte es genommen, > wenn 80% der gewünschten Funktionen schon drin gewesen wären. Aber das > war halt nicht der Fall. Am Ende haben sie sich für eine komplett neue > Anwendung in Java entschieden (an der arbeitet mein Team seit 1,5 > Jahren). Da spielt sicher auch eine Rolle, das sowohl unsere Entwickler > als auch die des Kunden sich mit Java EE viel besser auskennen. Python > wäre Neuland gewesen. Nunja, ich würde sicherlich sehr lange und intensiv nachdenken, bevor ich eine Entscheidung wie Eure treffe. Anstatt als Basis eine Software in Python zu benutzen, die schon -- sagen wir -- 50% der Anforderungen erfüllen kann (und die ihrerseits erweiterbar ist), entwickelt Ihr eine vollständig neue Software... Das erscheint mir nur dann sinnvoll, wenn man keine Python-Expertise im Hause hat (oder man als externer Dienstleister lieber einen großen Entwicklungsauftrag an Land zieht anstelle eines kleinen Wartungsvertrages, nix für ungut). ;-) Nunja, wie auch immer: Ich habe leider nicht gerade den Eindruck, daß Deine letzten Ausführungen Deine frühere Aussage bestätigen, Python sei per se langsam. Ein an eine relationale Datenbank "angeschlossene" ERP-Umgebung wird meiner Erfahrung nach ohnehin den größten Teil ihrer Laufzeit mit dem Warten auf das Datenbank-Backend verbringen -- und das bisschen Ausfüllen von kompilierten Templates mit den Daten aus der Datenbank ist dabei meist relativ vernachlässigbar. Bei meinen Web-Applikationen haben die Datenbackends jedenfalls meistens sehr viel mehr Last und einen viel höheren Anteil an der Gesamtperformance als Applikation, Webserver, und Reverse Proxy.
> Weil andere Datentypen gibt es in Assembler nicht. ja, die Erde war schon immer eine Scheibe >Wenn es nicht stimmt - und es stimmt nicht - dann ist es kein Argument. Doch, die Endekennung fehlt! (Wäre gut für Boing, um noch weitere Abstürze zu produzieren ) > Fand ich anfangs auch scheiße, .. warum wohl.
S. R. schrieb: > Stefan ⛄ F. schrieb: >> Und die Performance [von Python] ist selbst auf einem >> Quad Core PC eher traurig. > > Erstaunlich positiv überrascht war ich vor vielen Jahren von Perl, > extrem negativ überrascht von Ruby. Aber Python ist jetzt kein > besonderes Beispiel von Langsamkeit. Naja, seinerzeit war einer der weniger wichtigen Gründe, von Perl zu Python zu wechseln, daß Python (damals) erheblich performanter war als Perl, Ruby, und PHP. Wichtiger war mir allerdings die klare, pseudocodeähnliche Syntax, mit der ich mir keine Gedanken mehr machen mußte und muß, wie ich meine Ideen formuliere, sondern sie direkt aus meinem Gehirn in den Editor gießen kann... > Mit der Einrückung muss man sich abfinden. Fand ich anfangs auch > scheiße, inzwischen nicht mehr. Es hängt natürlich auch davon ab, ob man einen ordentlichen Editor benutzt... Mit Notepad.exe macht das sicherlich keinen Spaß. ;-)
> ich mir keine Gedanken mehr machen > mußte und muß, wie ich meine Ideen formuliere, sondern sie direkt aus > meinem Gehirn in den Editor gießen kann... Oh Schreck. Was haben die Leute denn die letzten 50 Jahre gemacht?
MCUA schrieb: >> ich mir keine Gedanken mehr machen >> mußte und muß, wie ich meine Ideen formuliere, sondern sie direkt aus >> meinem Gehirn in den Editor gießen kann... > Oh Schreck. > Was haben die Leute denn die letzten 50 Jahre gemacht? Länger nachdenken müssen als ich das mittlerweile muß. ;-)
Sheeva P. schrieb: > Einen endlosen Roman Bitte nimm es mir nicht übel, aber wenn ich Hilfe zu Oddo/Python brauche, mache ich das in einem eigenen Thread. Brauche ich aber gerade nicht, weil das Management dagegen entschieden hat. Es macht auch keinen Sinn, mit mir zu diskutieren, ob die Leute gut oder schlecht entschieden haben. Wichtig ist, dass sie mir Arbeit beschaffen, und das haben sie getan.
Stefan ⛄ F. schrieb: > Sheeva P. schrieb: >> Einen endlosen Roman > > Bitte nimm es mir nicht übel, aber wenn ich Hilfe zu Oddo/Python > brauche, mache ich das in einem eigenen Thread. Dabei ging es allerdings im Wesentlichen um PostgreSQL.
小さな猫の女の子 schrieb: > Ich kann auch nicht genau beantworten, was das PHP machen soll oder für > was es verwendet wird, da ich mich damit nicht auskenne. Die Frage kommt > von meinem Kollegen mit dem ich das Projekt zusammenbetreibe. Er hat > auch die Dateien für die Webseite geschrieben. Du bist also nicht fähig deinen Kollegen zu fragen und diese Frage hier weiterzuleiten? 100 Trollpunkte! Und noch 42 für den Fakt, dass anscheinend der Falsche hier fragt und so praktisch die wichtigste Frage (dem exakten Verwendungsgrund für PHP auf einer MCU) gekonnt als nicht beantwortbar suggeriert. Was für ein Zufall?! Ein weiterer Grund, dass dieses Unterfangen Blödsinn sein könnte ist die Größe der Binärdistribution von PHP (ohne dem entsprechenden Gerüst zur Ausführung von PHP). Viel Erfolg das auf einen Mikrocontroller zu bringen. Meiner Meinung nach bist Du im falschen Ökosystem und solltest die oben genannten Alternativen nutzen. Für 142 Trollpunkte gibt es übrigens Beratungsresistenzseife und eine Flasche Schnaps-Idee. Gratis dazu: Das Teamfähigkeits-Dosentelefon:P
MCUA schrieb: >>Wenn es nicht stimmt - und es stimmt nicht - dann ist es kein Argument. > Doch, die Endekennung fehlt! > (Wäre gut für Boing, um noch weitere Abstürze zu produzieren ) Du entscheidest auch sonst auf Basis von Aussagen, von denen du weißt, dass sie falsch sind? Klingt, als ob du in erster Linie von großer Intelligenz beseelt bist. /s Sheeva P. schrieb: > Naja, seinerzeit war einer der weniger wichtigen Gründe, > von Perl zu Python zu wechseln, daß Python (damals) erheblich > performanter war als Perl, Ruby, und PHP. Hmm, also bei meinen letzten Vergleichen hat sich Perl deutlich schneller durch die Textdateien gebissen als Python; das war aber auch massives Regex-Foo. Mit Ruby und PHP arbeite ich nicht, daher kann ich die nicht vergleichen.
小さな猫の女の子 schrieb: > da > ich mit jemand zusammen das Projekt mache und er vorallem das mit der > Webseite gemacht hat und mich gefragt hat, ob es eventuell möglich wäre. Jedzia D. schrieb: > Du bist also nicht fähig deinen Kollegen zu fragen und diese Frage hier > weiterzuleiten? 100 Trollpunkte! Hat er doch klar kommuniziert: Er weiß es nicht wozu. Es war nur eine prinzipielle Frage die ganz schnell mit "Nein" beantwortet wurde. Bis die üblichen Kasperln eine Diskussion um $irgendwas daraus gemacht haben.
S. R. schrieb: > Sheeva P. schrieb: >> Naja, seinerzeit war einer der weniger wichtigen Gründe, >> von Perl zu Python zu wechseln, daß Python (damals) erheblich >> performanter war als Perl, Ruby, und PHP. > > Hmm, also bei meinen letzten Vergleichen hat sich Perl deutlich > schneller durch die Textdateien gebissen als Python; das war aber auch > massives Regex-Foo. Mit Ruby und PHP arbeite ich nicht, daher kann ich > die nicht vergleichen. Naja, ich habe das seinerzeit mal gemacht, und damals (lange her) wies Python2 tatsächlich die höchste Performanz auf. Aber: die anderen haben wohl mittlerweile deutlich aufgeholt... zumindest gegenüber dem Standardinterpreter. ;-) Ob sie auch mit Pypy mithalten können? Hmmm... Bei Regular Expressions würde ich das aber mal stark annehmen, schließlich ist Python die einzige dieser Sprachen, bei der die Regex-Engine kein fest einkompilierter Teil des Sprachkerns ist.
Sheeva P. schrieb: > Aber: die anderen haben wohl mittlerweile deutlich > aufgeholt... So ist es. In einer Phase als es um Perl bereits ziemlich ruhig wurde, fanden noch erstaunlich weit reichende Optimierungen statt. Ich habe das auch nur zufällig mitbekommen als ich mal Gigabytes von Textdateien analysieren musste. Normalerweise mache ich das mit awk, aber irgend ein Feature fehlte mir dort, deswegen wich ich auf Perl aus - und wurde positiv überrascht. Dennoch gammelt Perl auch bei mir in einer einsamen Nische herum, aus der es nur selten heraus geholt wird.
Stefan ⛄ F. schrieb: > Sheeva P. schrieb: >> Aber: die anderen haben wohl mittlerweile deutlich >> aufgeholt... > > So ist es. In einer Phase als es um Perl bereits ziemlich ruhig wurde, > fanden noch erstaunlich weit reichende Optimierungen statt. Ich habe das > auch nur zufällig mitbekommen als ich mal Gigabytes von Textdateien > analysieren musste. Normalerweise mache ich das mit awk, aber irgend ein > Feature fehlte mir dort, deswegen wich ich auf Perl aus - und wurde > positiv überrascht. Lustigerweise hat nach meinem Eindruck erst die hohe Performance von Python einige der Skriptspracheninterpreter dazu animiert, an der Performance zu schrauben. Aber es ist schon ein gewisser Anachronismus, daß wegen der schwächeren Hardware die Performance des Interpreters viel wichtiger war als heute und zumindest der Standardinterpreter von Python nicht viel an der Schraube gedreht hat. Übrigens, was so RegEx-Engines angeht, habe ich vor einiger Zeit mal ein paar kleine Experimente mit der RegEx-Engine von C++ gemacht und festgestellt, daß das gute alte grep(1) immer noch um Größenordnungen schneller war... > Dennoch gammelt Perl auch bei mir in einer einsamen Nische herum, aus > der es nur selten heraus geholt wird. Ach, ich benutze perl(1) auch nurmehr (meist mit -pe) als Filter auf der Shell, das ist für mich meistens einfacher als grep(1), awk(1) und sed(1).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.