Das Raspberry Pi 3 ist nun auch in der miniaturisierten Compute Module Version verfügbar. Die CM Version des Raspberry Pi ermöglicht eine einfache Integration der beliebten Plattform in eigene Produkte, speziell im industriellen Bereich. Gegenüber der Standardversion sind hier 120 statt 40 IO Pins verfügbar, wobei das Modul lediglich die Größe eines DDR2-SODIMM-Speicherriegels aufweist.
Wie schon bei der Standardvariante des Raspberry Pi 3 kommt ein 64-Bit-Broadcom BCM2837-Prozessor zum Einsatz, welcher auf dem ARM Cortex-A53 mit vier Kernen basiert. Getaktet wird der Prozessor mit bis zu 1,2 GHz, das kleinere Modul besitzt ebenfalls einen Gigabyte Arbeitsspeicher. Darüber hinaus ist die neue Version weitestgehend kompatibel zu dem 2014 vorgestellten CM1, das nur etwa ein Zehntel der Rechenleistung eines Raspberry Pi 3 bietet.
Das CM3 ist in zwei Versionen verfügbar. Die Standardversion bietet 4GB integrierten Flash, wohingegen die Light Version ohne eigenen eMMC-Speicher auskommt. Dafür bietet das CM3L genannte Modul die Möglichkeit, den Speicher extern über ein SD Interface zu erweitern.
Die Module und für Evaluationszwecke passende Interfaceplatinen mit benötigten Buchsen und Stiftleisten sind bei RS Components und Farnell verfügbar. Bei Farnell kostet die Standardvariante derzeit 29€, in der Light Ausführung gibt es das Modul ab 24€.
Is schon irre, Vierkern-CPU + 1 GB RAM für läppische 25 Euro auf so
einem Speicherriegel. Fragt sich nur, ob man irgendwann auch mal
passende Software bekommt, welche die vier Kerne WIRKLICH ausnutzt.
Falk B. schrieb:> Fragt sich nur, ob man irgendwann auch mal> passende Software bekommt, welche die vier Kerne WIRKLICH ausnutzt.
Bestimmt kommt auch das noch wenn es das nicht schon gibt. Ich meine das
Boinc-Project kann das schon, oder?
Es sollte alles funktionieren was auf Linux läuft (z.B. Raspbian). Eine
Limitierung ist der fehlende Kühlkörper. Mit Einstein @ Home auf dem
BCM2837 fängt dieser an zu throttlen (80°C Limit).
Falk B. schrieb:> Is schon irre, Vierkern-CPU + 1 GB RAM für läppische 25 Euro auf so> einem Speicherriegel. Fragt sich nur, ob man irgendwann auch mal> passende Software bekommt, welche die vier Kerne WIRKLICH ausnutzt.
Das ist doch die Aufgabe des Nutzers eines solchen Moduls (also
typischerweise ein Entwickler) die richtige Software einzusetzen. Sehr
viel Software profitiert heute schon von mehreren Kernen. Angefangen von
so simplen Sachen wie make bis hin zu Webservern.
Matthias
@Μαtthias W. (matthias) Benutzerseite
>> Is schon irre, Vierkern-CPU + 1 GB RAM für läppische 25 Euro auf so>> einem Speicherriegel. Fragt sich nur, ob man irgendwann auch mal>> passende Software bekommt, welche die vier Kerne WIRKLICH ausnutzt.>Das ist doch die Aufgabe des Nutzers eines solchen Moduls (also>typischerweise ein Entwickler)
Ja wer denn nun? Die allermeisten NUTZER haben sicher nicht die
Fähigkeit und Interesse, einen Linuxkernel + Drumherum an eine 4-Kern
CPU anzupassen.
> die richtige Software einzusetzen. Sehr>viel Software profitiert heute schon von mehreren Kernen. Angefangen von>so simplen Sachen wie make bis hin zu Webservern.
Jaja, schöne Theorie, aber wie sieht die PRAXIS aus? Gibt es
mittlerweile brauchbare Software, welche die 2-Kern Version der Himbeere
gescheit ausnutzt?
Falk B. schrieb:> @Μαtthias W. (matthias) Benutzerseite>>>> Is schon irre, Vierkern-CPU + 1 GB RAM für läppische 25 Euro auf so>>> einem Speicherriegel. Fragt sich nur, ob man irgendwann auch mal>>> passende Software bekommt, welche die vier Kerne WIRKLICH ausnutzt.>>>Das ist doch die Aufgabe des Nutzers eines solchen Moduls (also>>typischerweise ein Entwickler)>> Ja wer denn nun? Die allermeisten NUTZER haben sicher nicht die> Fähigkeit und Interesse, einen Linuxkernel + Drumherum an eine 4-Kern> CPU anzupassen.
Der Endnutzer sicher nicht. Aber dem ist es auch herzlich egal wie viel
Kerne so eine CPU hat solange das "Gerät" ausreichend schnell arbeitet.
Und der Entwickler brauch sich um den eigentlichen Kernel nicht zu
kümmern wenn er nicht will da der ja schon angepasst ist und alle vier
Kerne des Raspi unterstützt. Der muss einfach nur die zu erfüllende
Aufgabe auf mehrere Threads/Prozesse verteilen.
>> die richtige Software einzusetzen. Sehr>>viel Software profitiert heute schon von mehreren Kernen. Angefangen von>>so simplen Sachen wie make bis hin zu Webservern.>> Jaja, schöne Theorie, aber wie sieht die PRAXIS aus? Gibt es> mittlerweile brauchbare Software, welche die 2-Kern Version der Himbeere> gescheit ausnutzt?
Jeder Webserver der mehr als einen Thread bzw. Prozess benutzt z.B.?
Mittlerweile sind auch die meisten Webbrowser multihtreaded oder lassen
einzelne Tabs in unterschiedlichen Prozessen laufen. Für die
Softwareentwicklung nutzt z.B. make mehrere Prozesse. Wenn mehrere
Programme laufen nutzen diese mehrere Kerne.
In der Firma haben wir z.B. eine Anwendung bei der ein Thread die
Visualisierung übernimmt, ein Thread macht die Logik, einer die
Kommunikation und einer überwacht das ganze.
Matthias
Es gibt fertige Linux Images die aktuell sind und gewartet werden, bspw.
Raspbian (basiert auf Debian) wie oben geschrieben.
Welcher Pi hat 2 Kerne? Es gibt BCM2835 mit 1 Kern, sowie 4 Kerne auf
BCM2836 & BCM2837.
Μαtthias W. schrieb:> In der Firma haben wir z.B. eine Anwendung bei der ein Thread die> Visualisierung übernimmt, ein Thread macht die Logik, einer die> Kommunikation und einer überwacht das ganze.
Sowas ist aber dann eher ein Thema der Code-Struktur, und weil viele
Bibliotheken mit blockierenden Aufrufen bei I/O arbeiten.
Die Strukturierung ist dann nicht so gewählt, damit man die Cores
ausnutzen kann, sondern weil es die Wartbarkeit des Programms erhöht
bzw. weil alles non-blocking und Event-Basiert garnicht möglich wäre.
Gut, ich kenn jetzt das von dir angesprochene Programm nicht,
aber GUI-Thread, I/O-Thread und Backend-Logik-Thread hört sich
für mich nicht nach etwas an was prinzipiell 4 Prozessor-Kerne braucht.
Ich nehme an, ffmpeg läuft unter Raspbian. Da hätten wir dochmal
ein Programm, was 4 Kerne nutzen könnte für Video-Transcoding.
Oder ein Programm, was sehr viele Bilder skalieren muss, kann
das auf mehrere Threads auslagern.
An sich, also vom Betriebssystem und von der Performance her muss
eigentlich kaum etwas wirklich echt Parallel laufen. Für alles gibt
es (echt) Asynchrone I/O-APIs und/oder Non-Blocking I/O mit
select()/kqueue()/usw. Will sagen: Wenn der Flaschenhals I/O ist,
dann bringen einem mehr Kerne nix.
Robin R. schrieb:> Gut, ich kenn jetzt das von dir angesprochene Programm nicht,> aber GUI-Thread, I/O-Thread und Backend-Logik-Thread hört sich> für mich nicht nach etwas an was prinzipiell 4 Prozessor-Kerne braucht.
Kein Programm braucht prinzipiell vier Kerne. Aber ein Programm was
schon von sich aus mehrere Threads/Prozesse besitzt profitiert ganz
automatisch von mehreren Kernen (wenn da keine anderen limitierenden
Faktoren im Spiel sind wie eben I/O).
Ich denke aber über Sinn und Unsinn von Mehrkernrechnern muss man nicht
diskutieren. Das ist einfach Standard. Und es gibt jede Menge Software
die davon profitieren kann. Mehr wollte ich jetzt garnicht dazu sagen.
Matthias
Für Produkte mit Langzeitverfügbarkeit ist das auch noch nix. Es gibt ja
nichtmal ein vernünftiges Datenblatt des BCM2837. Für den
Industrieeinsatz also ein bisschen zweifelhaft. Zumindest für lang
laufende Projekte.
Markus C. schrieb:> Nur die Lifetime January 2023. ist etwas unschön
Stimme ich total zu. Das sind gerade mal knappe 6 Jahre.
Wenn die Entwicklung eines Produktes auf der Basis jetzt starten
würde, dann könnte man das ggf. - optimistisch? - evtl. in 1 Jahr
zum Kunden schicken. Dann sind das nur noch 5 Jahre.
Damit sich die Entwicklung dann rentiert, muss man noch gut
Verkaufen, und bis dann die ganzen Inbetriebnahmen gelaufen
sind und man keine neuen Geräte mehr verkauft, haben wir 2020.
Und dann hängt das Ding in Produktion in einem Schaltschrank
und die 3 Jahre verfliegen bis ein Blitzschlag dann ein Ersatzgerät
einfordert. "Ja, ähm, wir haben die Hardware leider nicht mehr.
Sie müssen 6 Monate warten, bis wir die Software und die Elektronik
angepasst haben."
Wenn ich .xz komprimiere merke ich von den vier kernen meiner intel i5
cpu schon dass es vier mal schneller geht als single core
XZ_OPT=-9 tar cvf foo.tar.xz foo --use-compress-program=pxz
Mag jemand damit ein Netbook entwickeln?
Es gibt ja die Gehäuse mit denen sich einen Raspberry in einen 13"
Laptop verwandeln lässt. Mit dem Modul geht das bestimmt
flacher/kleiner. Auch das Beispiel bei dem sich jemand damit ein Tablet
gebaut hat und dafür aus Platzgründen (Höhe) die USB Buchsen runter
löten musste, kommt mir als geeigneter Einsatz für das Modul in den
Sinn.
Achja, soo schwer ist Thread Programmierung nun auch nicht um alle Kerne
auszulasten. Ist bei Videokodierung oder beim Compilieren regelmäßig der
Fall. Zugegeben, nicht unbedingt die Aufgaben die man üblicherweise auf
einem Raspberry ausführt.
Malte _. schrieb:> Achja, soo schwer ist Thread Programmierung nun auch nicht um alle Kerne> auszulasten. Ist bei Videokodierung oder beim Compilieren regelmäßig der> Fall.
Das sind gleich zwei Beispiele von Programm-Klassen mit hoher
Komplexität, die ich nun nicht gerade als "trivial" oder "nicht soo
schwer"
einstufen würde.
Gut, beim Compilieren kann man relativ gut einzelne unabhängige
(die als solches erstmal eingestuft werden müssen => hier muss ein
entsprechend gutes Build-System vorhanden sein) Objekte erzeugen,
die dann später durch den Linker zusammengefügt werden - klassisches
Teilen und Herrschen.
Beim Videoencoden nehme ich an, wird auch via Teilen & Herrschen
verfahren. Ich weiss nicht genau wie, aber beim Raytracing werden
einzelne Bildbereiche oder Blöcke aus dem Ziel-2D-Raum auf mehrere
Threads
verteilt.
Hier sollte man ggf. auch nicht zu sehr am Begriff "Thread" hängen,
denn viele dieser Aufgaben lassen sich auch auf mehrere "Prozesse"
verteilen, die sogar auf mehrere vernetzte Rechner verteilt werden
können (man denke an die tollen Computer auf der TOP500 Liste
https://www.top500.org/lists/2016/11/ ).
Ein Nachteil von Threads bei der Parallelisierung für die
Skalierung intensiver Rechenprobleme ist die notwendige Synchronisation
des gemeinsamen Speichers. Die MMUs der CPU-Kerne müssen sich darüber
austauschen, wer und wofür welche Speicherseiten reserviert wurden.
Dadurch haben wir wieder Blockierungen zwischen den CPUs, die man
ja eigentlich umgehen will für maximalen Durchsatz.
Der Verzicht auf Threads bringt auch oft Vorteile mit sich, schließlich
ist ja gerade ein Firefox in Entwicklung, der einzelne Webseiten auf
mehrere Prozesse (nicht Threads) aufteilt. Das bringt bei Multi-Core
Rechnern natürlich Vorteile, aber es ist auch ein großer Aspekt der
Entkoppelung der Seiten voneinander dabei. So crasht ein abstürzendes
Webseiten-Plugin nicht gleich alle anderen angezeigten Webseiten mit.
Bei Google Chrome ist da ja schon länger Gang und Gäbe.
Mehrere Kerne haben natürlich auch Vorteile, denn die Programme die
vorher auf einer CPU langsam liefen, können nun parallel auf einem
eigenen CPU-Kern langsam ausgeführt werden. Das ist doch schonmal
ein Vorteil. Wobei man wohl nur selten diese Beobachtung machen könne
wird auf modernen Windows-PCs, weil dort die meisten Programme
mit denen man zu tun hat, auf die Festplatte oder das Netzwerk
warten. Beides nicht hinreichend parallelisierte Ressourcen wohlgemerkt.
Insbesondere wirds nervig wenn wieder irgendein Windows-Indexer-
oder Defender-Service nach jedem Reboot meint die 1TB Daten einmal
neu durchsuchen zu müssen - auf einer nicht-SSD-Platte.
Da sehe ich den Einsatzort für das Compute-Module durchaus nur in
der Live-Bildverarbeitung, bei der es ausreichend schnell ist. Und auch
nur bei Produkten, bei denen Time2Market höchstes Ziel ist.
Raspbian existiert, man hat eigene Peripherie, und nun möchte man fix
seine Raspberry-Anwendung auf ein eigenes Board bringen in einem
"flotten" Gehäuse für den Consumer-Markt, oder einen
Markt für experimentierfreudige Entwickler.
Thread beobachten
Seitenaufteilung abschalten