Wann kommt der Raspberry Pi 5? Offizielle Infos zum Raspberry Pi 4 Nachfolger

[Jochen]

Kurz rein gereicht:

Neuer RasPi5

https://www.heise.de/hintergrund/Ras...g-9319020.html

[U-Labs YouTube]

Antwort von @yt7042:
@ULabs Danke für die gespiegelte Antwort. In der aktuellen Situation werden die Gelder für Entwicklung sicher eher gekürzt. Mit Konkurrenz meine ich auch eher stromsparende Mini PCs ohne GPIO PINS. Apple ist eher ein Sonderfall, bei deren Prozessor Hin- und Her geht es wohl eher um marktstrategische Gründe und weniger um einen Mehrwert.

[DMW007]

Bei der Effizienz sind die M-Prozessoren von Apple gut aufgestellt. Das kann schon was bringen, gerade bei PCs die viel laufen und häufiger ausgelastet sind. Oder schlicht eine längere Akkulebensdauer für Notebooks unterwegs. Da steckt schon mehr dahinter, als bei den X86 Macs. Das war am Ende bloß Hardware von Intel. Keine schlechte, aber die bekommt man ohne Apple deutlich günstiger - oder alternativ für mehr Geld stärkere Komponenten. Apple langt da ordentlich zu. Alleine was die für eine Speichererweiterung verlangen, ist heftig. Damit Kunden die auch in Anspruch nehmen, wird gerne verlötet. Sonst könnte manch einer den Speicher für den Bruchteil des Apple-Preises kaufen und selbst einbauen.

Ich stimme dir allerdings zu, dass strategische Gründe ebenfalls eine Rolle spielen. Apple war abhängig von einem Konkurrenten, das möchte man als souveränes Unternehmen ungern haben. Insbesondere nachdem Apple die Ressourcen hat, ist es aus ihrer Sicht schon deswegen sinnvoll.

[U-Labs YouTube]

Antwort von @OpenGL4ever:
@ULabs Das Problem der Treiber für irgendwelche proprietäre Peripheriehardware, die auf die SoCs kommt, wird auch nicht mit RISC-V gelöst. RISC-V ist ja nur die Prozessorarchitektur. RISC-V erlaubt es den SoC Herstellern Lizenzgebühren zu sparen, das war es dann aber auch schon mit der Freiheit. Die Anwender haben recht wenig davon. Wer Freiheit will, der läuft momentan mit x86 CPUs immer noch am besten.

[DMW007]

Weitere Hardware ist was anderes. Mit ARM ist das Problem: Damit scheitert man garantiert am Prozessor, weil ARM proprietäre CPU-Designs verkauft. Eine Lizenz das quelloffen verbreiten zu dürfen, werden sie daher nicht erteilen - damit wäre ihr Geschäftsmodell erschöpft. Mit RISC-V fällt dieses Problem weg und die Lizenzkosten ebenfalls. Zumal man damit unabhängig ist. Wenn ARM die Preise erhöht, kannst du als Lizenznehmer bestenfalls noch deine Marge etwas senken, falls der Wille dafür da ist. Fehlt der oder die Teuerung ist zu hoch, wird das Endprodukt teurer. Gerade im SoC-Bereich hat ARM ein Quasi-Monopol. Hier hätte ich gerne mehr Wettbewerb. Für X86 schadet es ebenfalls nicht, da haben wir mit Intel & AMD überschaubare Auswahl.

Prozessoren auf RISC-V Basis sehe ich aus diesen Gründen als sinnvolle Grundlage, um autonomer zu werden und zeitgleich einen wichtigen Schritt in Richtung quelloffener Hardware zu gehen. Über Nacht wird man solch eine Industrie ohnehin nicht verändern. Insbesondere, nachdem RISC-V in der Praxis noch hinterher hinkt. Selbst wenn man ein paar Euro spart (was bei der aktuellen Produktionsmenge kaum der Fall ist), steht die Software-Unterstützung deutlich schlechter dar. Rein kapitalistisch Gedacht lohnt sich das daher momentan absolut nicht.

Bis sich das ändert stimme ich dir zu, dass X86 derzeit in Richtung Freiheit am sinnvollsten ist.

[U-Labs YouTube]

Antwort von @letmedwight:
@ULabs ich habe momentan Windows 11 ARM auf einem Raspberry Pi 3 1Gb installiert.
Es funktioniert zum testen von simplen windows ARM Anwendungen, aber auch nur gerade so und wenn man viel geduld übrig hat!
Die frage von mir ist nur, ob ich win11 auf nen raspberry 4 8GB installieren sollte oder gleich auf den Raspberry pi 5 warten? Um eine halbwegs nutzbare performance zu haben.
Bei dem raspberry pi 3 1gb habe ich herausgefunden, das ein simples 2d spiel mit sekunden pro bild und nicht mit bild pro sekunde läuft (zumindest beim Pi3 1GB) da die 4er ja alle leider ausverkauft sind...

[U-Labs YouTube]

Antwort von @OpenGL4ever:
@letmedwight Dein Fehler liegt in der OS Wahl. Was willst du mit Windows? Zwar wurde Windows NT prozessorarchitekturunabhängig entwickelt, aber den größten Teil der Software gibt es nur für x86. Windows hat somit auf anderen Architekturen überhaupt keinen Nutzen. Zumindest kriegst du nicht das, was du auf dem x86 PC gewohnt bist.
Wenn du Windows willst, dann kauf dir einen x86 PC. Und wenn du einen Raspberry Pi willst, dann lerne mit Linux umzugehen.

[U-Labs YouTube]

Antwort von @letmedwight:
@OpenGL4ever ganz einfach. Ich peogrammiere software für linux x64 und windows x64 und arm64 und d mir ein devkit von microsoft für 700 euro zu teuer ist. Spiele ich halt windows ARM auf nen raspberry pi.

[U-Labs YouTube]

Antwort von @OpenGL4ever:
@letmedwight Wozu? Welchen Markt willst du für Windows ARM bedienen?
Ach so nur als Hobby, ah ja klar.

Übrigens, wenn man für Windows entwickelt, dann kann man x86 nehmen, dann hat man auch mehr Leistung. Da kannst du dann für ARM crosscompilen, fertig.

[U-Labs YouTube]

Antwort von @letmedwight:
@OpenGL4ever
Ich gehe davon aus, dass der "Markt" für Windows ARM Konsumenten (noch) kommen wird. Momentan hat Microsoft ja nur ihre Devkits veröffentlicht von "Project Volterra", aber ich sehe da sehr viel Potenzial aufgrund ihres deutlich geringeren Stromverbrauchs und dem bereits jetzt vorhandenen Kompatibilitätsmodus, mit auch x86/x64 Programme, welche zwar nicht so gut laufen wie arm64 Programme, aber trotzdem kompatibel sind.

Warum jetzt nach deiner Meinung "x86" mehr Leistung bieten soll, kann ich in keinster weiße nachvollziehen...
Zum einen wäre bereits bei 4GB Arbeitsspeicher Schluss und zum anderen ist die Latenz länger, wenn ein 64bit System, eine 32bit Anwendung erst einmal übersetzen muss, anstatt direkt eine 64bit Anwendung zu nehmen.

(Letzteres habe ich selber sogar getestet)
mit einem Werkzeug, das mir die Latenz und FPS anzeigt und habe beides sowohl 64bit, als auch 32bit laufen lassen. Das Ergebnis war:
Die 32bit Anwendung hatte eine Reaktionszeit von "60ms", während die 64bit Anwendung eine Reaktionszeit von "36ms" hatte.

- Es handelte sich um die gleiche Software mit den gleichen Inhalten von mir, nur hatte ich es sowohl als auch 1x für x86 und 1x für x64 exportiert.