Connect with us

Entwicklung & Code

Asynchrone Programmierung – Teil 3: Parallelität in C++ mit Qt6


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Das Qt6-Framework ist insbesondere wegen seiner mächtigen Werkzeuge zur Erstellung von Bedienoberflächen für eingebettete Geräte mit C++ weit verbreitet. Doch die Einsatzzwecke gehen über Embedded hinaus.

Weiterlesen nach der Anzeige


Martin Meeser

Martin Meeser

Martin Meeser ist selbständiger Diplominformatiker (Uni) und bietet Dienstleistungen zum Thema Softwareentwicklung an: Individual-Software-Entwicklung, Beratung zu Prozessen und Schulungen. In zahlreichen Projekten betreute er bisher Kunden unter anderem aus den Bereichen Automotive, Finance, Raumfahrt, Radioastronomie und Medizintechnik.

Dieser Artikel ist der dritte Teil aus der Serie „Asynchrone Programmierung“, die Mechanismen und Frameworks für die effiziente und nachhaltige Entwicklung von nichtlinearen Programmabläufen in verschiedenen Sprachen vorstellt. Asynchrone Programme benutzen keine fehleranfälligen und schwer zu debuggenden Thread-Mechanismen wie Locks und Semaphoren, sie verschwenden folglich keine Ressourcen durch Blockieren von Threads und sie skalieren nativ mit den zur Verfügung stehenden Prozessorkernen.

Im Gegensatz zu den bereits vorgestellten Mechanismen der Boost::Asio-Bibliothek, die de facto den C++ Standard darstellen und daher möglichst nativ in C++ eingebettet sind, bietet Qt aus seiner Historie heraus ein Event-System: den Qt-eigenen Signal-Slot-Mechanismus, QThreadPool und – etwas neuer – QFuture und QPromise.

Auf aktuellen Debian- und Ubuntu-Linuxen kann man Qt6 über die bekannte Paketverwaltung APT installieren:

sudo apt install qt6-base-dev

Dies installiert derzeit die Version 6.8.2. Möchte man die neueste Version (aktuell 6.10.2) verwenden oder arbeitet man mit einem anderen System, benötigt man für den Download einen Benutzeraccount bei der Qt Group, dem Unternehmen, das Qt entwickelt. Qt ist in verschiedene Module aufgeteilt. Die Beispiele in diesem Artikel benötigen QtCore, das in jedem Qt-Projekt erforderlich ist und Grundfunktionen liefert, sowie QtConcurrent für Nebenläufigkeit.

Die Programme lassen sich mit dem Tool qmake des Herstellers oder mit dem CMake-Paket von Qt6 bauen. Das folgende Listing zeigt eine typische Konfiguration in CMakeLists.txt für ein Qt6-Projekt ohne Bedienoberfläche.

Weiterlesen nach der Anzeige


cmake_minimum_required(VERSION 3.18)
project(MyQt6ConsoleApp VERSION 1.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

find_package(Qt6 REQUIRED COMPONENTS Core Concurrent)

qt_standard_project_setup()

qt_add_executable(MyQt6ConsoleApp
    src/main.cpp
)
target_link_libraries(MyQt6ConsoleApp PRIVATE Qt6::Core Qt6::Concurrent)

install(TARGETS MyQt6ConsoleApp
    RUNTIME DESTINATION bin


Listing 1: Ein typisches Beispiel für CMakeLists.txt für eine Konsolenanwendung mit Qt6

Events und die Event Loop von Qt

Die Hauptfunktion jeder Qt-Anwendung folgt dem gleichen Muster: Entwicklerinnen und Entwickler erzeugen eine Instanz der Hauptklasse, hier QCoreApplication, und rufen vor dem Beenden der Funktion die Methode exec() dieser Instanz auf, um die Event Loop von Qt zu starten.

Event Loops stellen die Mechanismen und die API für die asynchrone Entwicklung bereit und orchestrieren den Programmablauf. Die Event Loop von Qt nimmt auch Ereignisse vom Betriebssystem entgegen und leitet diese weiter. Das Grundgerüst einer Qt6-Anwendung mit Starten der Event Loop sieht folgendermaßen aus:


#include 

int main(int argc, char* argv[])
{
    QCoreApplication app(argc, argv);
    // ...
    return app.exec();


Listing 2: Grundgerüst einer Qt6-Anwendung, die eine Qt Event Loop startet.

Die Methode exec() springt erst beim Aufruf von QCoreApplication::quit() zurück. In diesem einfachen Beispiel wird das Programm also niemals von sich aus enden, der Hauptthread der Applikation wird für die Event Loop verwendet. Grafische Anwendungen verwenden statt QCoreApplication eine der Ableitungen dieser Klasse: QAndroidService oder QGuiApplication. Um auf Events reagieren zu können, muss die entsprechende Klasse von der Klasse QObject erben und die Methode event() oder customEvent() überschreiben. Alle Events stammen von der Klasse QEvent ab. Es gibt im Qt Framework eine Reihe von definierten Event-Klassen, zum Beispiel QEvent:Timer, QEvent:SockAct und QEvent:Quit. Entwickler können auch eigene Event-Typen erzeugen, indem sie eine von QEvent abgeleitete Klasse anlegen.

Mit der statischen Methode postEvent() der Klasse QCoreApplication werden konkrete Events an die Event Loop übergeben, wie folgendes Listing zeigt.


#include 

const QEvent::Type MyEventType = QEvent::Type(QEvent::User + 1);

class MyEvent : public QEvent
{
public:
    MyEvent(const QString& msg) : QEvent(MyEventType), message(msg) {}
    QString message;
};

class MyReceiver : public QObject
{
    Q_OBJECT
protected:
    void customEvent(QEvent* ev) override
    {
        if (ev->type() == MyEventType)
        {
            MyEvent* myEvent = static_cast(ev);
            qDebug() << myEvent->message;
            QCoreApplication::quit();
        }
    }
};

int main(int argc, char* argv[])
{
    QCoreApplication app(argc, argv);

    MyReceiver receiver;
    QCoreApplication::postEvent(&receiver, new MyEvent("Kind of async
  hello world!"));

    return app.exec();


Listing 3: Beispiele für asynchrone Ausführung mit einem eigenen Event-Typen.

Die Methode postEvent() reiht das Ereignis in die Warteschlange ein und springt sofort zurück. Bisher gibt es allerdings nur einen Thread: den Haupt-Thread. Das bedeutet, dass das Programm blockiert, sobald innerhalb der Ereignisverarbeitung Code läuft, der selbst blockiert. Auch ein lang andauerndes Event verzögert den gesamten Programmablauf, was zu einem für Anwenderinnen und Anwender wahrnehmbaren Einfrieren des Programms führt.

Daher hat sich in Qt bewährt, explizit einen oder mehrere Arbeiter-Threads („Worker Threads“) zu erzeugen. Dazu legt man eine neue Instanz der Klasse QThread an. Ein Aufruf der Methode QThread::start() führt innerhalb des QThread eine separate Event Loop aus.

In Qt gilt der Grundsatz der Thread-Zugehörigkeit („Thread Affinity“): Jedes QObject ist einem QThread zugeordnet, initial demjenigen, in dem es erstellt wurde. Die Event-Verarbeitung erfolgt immer in dem Thread, der dem QObject zugeordnet ist. Der Thread lässt sich mit der Methode QObject::moveToThread() jedoch wechseln.

Auf diese Weise verlaufen Aufgaben parallel, wie folgendes Listing exemplarisch zeigt.


// MyReceiver und MyEvent analog zu Listing 3

int main(int argc, char* argv[])
{
    QCoreApplication app(argc, argv);
    qDebug() << QThread::currentThreadId();

    MyReceiver receiver;
    QThread qThread;
    qThread.start();
    receiver.moveToThread(&qThread);

    QCoreApplication::postEvent(&receiver, new MyEvent(QString("Kind of async hello world from 2nd thread")));

    return app.exec();
}


Listing 4: Erstellen und Verwenden eines QThread mit eigener Event-Loop.

Die Methode postEvent() springt sofort zurück und der Code setzt keine komplizierten und fehleranfälligen Mechanismen wie Locks oder Semaphore ein, die Erstellung und Zuordnung einzelner Threads sind aber explizit. Dieses Beispiel skaliert also nicht automatisch mit den zur Verfügung stehenden Ressourcen, so wie es bei einem Threadpool der Fall ist. Die folgende Abbildung fasst die grundlegenden Klassen einer Qt-Anwendung in einem UML-Klassendiagramm zusammen.


Diagramm Qt-Klassen

Diagramm Qt-Klassen

UML-Klassendiagramm der grundlegenden Qt-Klassen



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Projektmanagement: Hat Dein Kalender ein Memory Leak?


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Wenn ein Team seine Sprint-Commitments regelmäßig nicht einhält, kann das eine Vielzahl von Gründen haben. Einer davon ist, dass neben der Arbeit an Sprint-Tickets noch weitere Dinge parallel laufen. Das können unerwartete Aufgaben sein, die man nicht in einem Ticket abbildet oder – wenn es ein Ticket gibt – es nicht in den Sprint zieht. Eine andere beliebte Quelle sind ausufernde Besprechungen mit bestenfalls geringem, schlimmstenfalls keinem Bezug zum Sprintziel.

Weiterlesen nach der Anzeige


Escape the Feature Factory: Stefan Mintert

Escape the Feature Factory: Stefan Mintert

(Bild: 

Stefan Mintert

)

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene.

Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind.

Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können.

Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Der schädlichste Fall sind Regelmeetings, die irgendwann vor vielen Jahren begonnen wurden. Damals waren sie vielleicht sinnvoll und produktiv. Doch heute sind sie oft nur „da“. Ohne Agenda, ohne klare Ergebnisse, mit einer „historisch gewachsenen“ Liste von eingeladenen Personen. Da es an Themen nicht mangelt, reicht die Zeit nie. Manchmal wird dann die Timebox vergrößert, ohne dass die Qualität steigt.

Wenn ich so etwas beobachte, frage ich die genervten Teilnehmer manchmal, weshalb sie dort hingehen. Einen echten Grund, der über „das machen wir immer so“ hinausgeht, höre ich nicht oft. Meine Vorschläge, die Teilnahme einfach mal abzusagen, sind offensichtlich irritierend radikal; mit anderen Worten: Man geht weiterhin zu diesen Besprechungen.

Zuletzt habe ich es mit folgender Analogie versucht: Der Kalender hat ein Memory Leak und diese Besprechungen sind belegter und nicht genutzter Speicher. Und welcher anständige Entwickler würde schon ein Memory Leak akzeptieren? Ungenutzten Speicher sollte man freigeben.

Diese Analogie hat tatsächlich Wirkung gezeigt, und es kam ein Dialog über die Frage auf, ob die Zeit, die die Meetings belegen, tatsächlich dem nicht genutzten Speicher entspricht. Ist es also sinnvoll investierte Zeit? Die Frage muss man natürlich im konkreten Fall entscheiden. Eine pauschale Antwort in diesem Beitrag kann es nicht geben.

Im Fall meines Kunden haben wir die Frage so geklärt, dass wir für die Besprechungen Tickets im Sprint angelegt haben. Damit haben wir zwei Fliegen mit einer Klappe geschlagen: Erstens war die früher unsichtbare Arbeitszeit jetzt sichtbar. Und zweitens kamen die Besprechungen im Review auf die Tagesordnung. Dort kann man zumindest gemeinsam über den Wert und den Nutzen der Besprechungen reden.

Weiterlesen nach der Anzeige

Erst lesen, dann handeln

Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung. Sie wirkt auch ohne Führungsposition. Mit dem Code „heisedev“ gibt’s den Heise-Rabatt für Interactive-Members.


(rme)



Source link

Weiterlesen

Entwicklung & Code

Ladybird-Browser integriert Rust mit Hilfe von KI


Das freie Browser-Projekt Ladybird hat einen wichtigen Schritt in Richtung Speichersicherheit vollzogen: Die Entwickler haben zentrale Komponenten ihrer JavaScript-Engine LibJS von C++ nach Rust portiert. Der Port umfasst rund 25.000 Zeilen Code und wurde mit Unterstützung von KI-Werkzeugen innerhalb von zwei Wochen umgesetzt.

Weiterlesen nach der Anzeige

Konkret wurden der Lexer, Parser, Abstract Syntax Tree (AST) und der Bytecode-Generator von LibJS übersetzt. Diese Komponenten eigneten sich laut Hauptentwickler Andreas Kling besonders gut für den ersten Port, da sie relativ selbstständig arbeiten und sich durch die test262-Suite umfangreich testen lassen. Alle 52.898 Tests der test262-Suite sowie 12.461 Ladybird-spezifische Regressionstests verliefen ohne Probleme – die Rust- und C++-Implementierung erzeugen byte-identische Ausgaben.

KI beschleunigte Übersetzung erheblich

Für die Übersetzung setzte Kling auf die KI-Modelle Claude Code und Codex, betont jedoch, dass es sich um eine Arbeit unter menschlicher Aufsicht (human-directed) handelte. Er steuerte den Prozess durch hunderte kleine Prompts und entschied selbst, welche Teile in welcher Reihenfolge portiert werden sollten. Nach der initialen Übersetzung führte er mehrere „adversarial“ Reviews durch, bei denen verschiedene KI-Modelle den Code auf Fehler und schlechte Muster prüften. Was manuell mehrere Monate gedauert hätte, war so in zwei Wochen erledigt.

Der resultierende Rust-Code trägt bewusst den Stil „translated from C++“, ist also nicht idiomatisches Rust. Diese Entscheidung fiel zugunsten der Kompatibilität mit der C++-Pipeline. Erst wenn die C++-Implementierung vollständig abgelöst wird, will das Projekt den Code in idiomatisches Rust überführen.

Kehrtwende nach Ablehnung 2024

Die Entscheidung für Rust ist bemerkenswert, da Ladybird die Sprache 2024 noch abgelehnt hatte. Damals argumentierten die Entwickler, Rusts Ownership-Modell passe nicht gut zum objektorientierten Stil der Web-Plattform mit ihren tiefen Vererbungshierarchien und Garbage Collection. Als Alternative wurde Swift evaluiert, scheiterte jedoch an unzureichender C++-Interoperabilität und limitiertem Plattform-Support außerhalb des Apple-Ökosystems.

Weiterlesen nach der Anzeige

Nach einem Jahr Stillstand entschied sich Kling nun pragmatisch für Rust. Als Gründe nennt er das reifere Ökosystem für die Systemprogrammierung, die verbreiteten Rust-Kenntnisse in der Contributor-Community und die Tatsache, dass auch Firefox und Chromium bereits Rust integrieren. Vor allem aber bietet Rust Speichersicherheitsgarantien, die C++ fehlen – ein kritischer Faktor für Browser-Engines, die häufige Angriffsziele sind.

C++ bleibt Hauptsprache

Einen vollständigen Ausstieg aus C++ plant Ladybird nicht. Die Sprache bleibt laut Kling die Hauptentwicklungssprache des Projekts. Der Rust-Port sei ein „Sidetrack, der lange läuft“. Neuer Rust-Code koexistiert mit bestehendem C++ über definierte Interop-Grenzen. Das Core-Team steuert bewusst, welche Komponenten wann portiert werden.

Ladybird entwickelt eine vollständig unabhängige Browser-Engine als Alternative zu den etablierten Engines Gecko (Firefox), Blink (Chromium) und WebKit (Safari). Noch befindet sich das Open-Source-Projekt in einer frühen Phase, eine erste Alpha-Version für Linux und macOS soll 2026 erscheinen.


(fo)



Source link

Weiterlesen

Entwicklung & Code

KI-Inferenz in Silizium gegossen: Taalas kündigt HC1-Chip an


Das 2023 in Kanada gegründete Start-up Taalas hat mit dem HC1 einen Technology Demonstrator angekündigt, der KI-Inferenz auf eine neue Stufe heben soll. Statt ein Sprachmodell per Software auf Allzweck-KI-Rechenbeschleunigern auszuführen, gießt Taalas das Modell sozusagen in Silizium. Das erste Produkt ist ein „fest verdrahtetes“ Llama 3.1 8B, das laut Herstellerangaben 17.000 Token pro Sekunde pro Nutzer erzeugen soll.

Weiterlesen nach der Anzeige

Laut Taalas bildet das Herzstück ein applikationsspezifischer Logikchip (ASIC) mit rund 53 Milliarden Transistoren, gefertigt bei TSMC im 6‑nm‑Prozess (N6) und 815 mm² Die‑Fläche.

Wie das Unternehmen in einem Blogbeitrag mitteilte, sei das nahezu zehnmal schneller als der aktuelle Stand der Technik. Zum Vergleich: Eine Nvidia H200 erreicht nach Nvidia-eigenen Baseline-Daten rund 230 Token pro Sekunde auf demselben Modell. Spezialisierte Inferenz-Anbieter wie Cerebras kommen laut den unabhängigen Benchmarks von Artificial Analysis auf rund 1.936 Token pro Sekunde – also etwa ein Neuntel des von Taalas beanspruchten Werts. SambaNova folgt mit 916 Token/s, Groq mit 609 Token/s.

Die Konkurrenz schläft jedoch nicht: Nvidia lizenziert seit Dezember 2025 Groqs Technik und hat große Teile des Designteams übernommen, um die eigene Position bei dedizierter Hardware zu stärken.

Testplattform läuft

Taalas stellt zum Ausprobieren den Chatbot „Jimmy“ bereit, der tatsächlich mit bemerkenswerter Geschwindigkeit antwortet – knapp 16.000 Token pro Sekunde waren im Test erreichbar. Einen Preis für den HC1 nennt das Unternehmen bislang nicht. Interessierte Entwickler können sich für den Zugang zu einer Inference-API registrieren.

Das vor zweieinhalb Jahren gegründete Start-up verfolgt drei Kernprinzipien: totale Spezialisierung auf einzelne Modelle, die Verschmelzung von Speicher und Rechenlogik auf einem Chip sowie eine radikale Vereinfachung des gesamten Hardware-Stacks. Taalas beansprucht, Speicher und Rechenwerk bei DRAM-typischer Dichte auf einem einzelnen Chip zu vereinen. Damit entfalle die bei herkömmlicher Inferenz-Hardware übliche Trennung zwischen langsamem Off-Chip-DRAM und schnellem On-Chip-Speicher.

Das verspricht Cerebras zwar auch, baut dazu aber seine gigantische Wafer Scale Engine (WSE), die einen kompletten Wafer belegt und 15 kW Leistung in Hitze verwandelt.

Weiterlesen nach der Anzeige

Kein HBM, keine Wasserkühlung, kein Advanced Packaging

Der Ansatz unterscheidet sich grundlegend von dem, was große Chiphersteller derzeit verfolgen. Nvidia setzt bei seinen KI-Beschleunigern wie dem H200 auf teures High Bandwidth Memory (HBM), aufwendige Gehäusetechnik (Packaging) und extrem hohe I/O-Datentransferraten.

Auch beispielsweise Googles TPU, Amazons Interentia oder Microsofts kürzlich angekündigter Azure-Beschleuniger Maia 200 nutzen bis zu 216 GByte HBM3E-Speicher bei einer Transferrate von 7 TByte/s. Microsoft verspricht zwar eine höhere Performance pro investiertem Dollar als bei Nvidia-Technik, doch Maia ist ebenfalls als Allzweckbeschleuniger für verschiedene KI-Modelle konzipiert.

Taalas eliminiert diese Komplexität, indem der HC1 ausschließlich für ein einzelnes Modell optimiert wird. Das Ergebnis komme ohne HBM, 3D-Stacking, Flüssigkühlung und Highspeed-I/O aus.

Bisher nur Mini-Modell

Das hat allerdings einen Preis in puncto Flexibilität. Der HC1 ist weitgehend fest verdrahtet – der Chip kann nur Llama 3.1 8B ausführen, nicht beliebige andere Modelle.

Llama 3.1 wurde Mitte 2024 vorgestellt, das ist im KI-Wettrüsten schon ein stattliches Alter. Die kompakte Version mit 8 Milliarden Gewichten (8 Billion, daher Llama 3.1 8B) läuft in quantisierter Form sogar auf einem Raspberry Pi 5 – wenn auch sehr langsam.

Immerhin lassen sich laut Taalas die Größe des Kontextfensters konfigurieren und per Low-Rank-Adapter (LoRA) Feinabstimmungen vornehmen. Zudem räumt das Unternehmen ein, dass die erste Silizium-Generation ein proprietäres 3-Bit-Datenformat nutzt, kombiniert mit 6-Bit-Parametern. Diese aggressive Quantisierung führe zu gewissen Qualitätseinbußen gegenüber GPU-Benchmarks mit höherer Präzision.

Nächste Generation soll Qualitätsprobleme lösen

Taalas plant, sehr schnell Nachfolger zu liefern. Der schlanke, automatisierte und schnelle Entwicklungsprozess für KI-ASICs ist das eigentliche Ziel des jungen Unternehmens. Es wurde von den Tenstorrent-Gründern Ljubisa Bajic und Drago Ignjatovic ins Leben gerufen. Beide waren zuvor länger für AMD tätig, Bajic auch für Nvidia. Wegen der prominenten Namen – derzeit leitet der bekannte Chipentwickler Jim Keller Tenstorrent – erheischt Taalas viel Aufmerksamkeit in der KI-Szene.

Gerade einmal 24 Teammitglieder hätten das erste Produkt realisiert, bei Ausgaben von 30 Millionen US-Dollar – von insgesamt über 200 Millionen eingesammeltem Kapital. Für einen N6-Chip mit 53 Milliarden Transistoren sind 30 Millionen US-Dollar Entwicklungskosten sehr wenig. Angesichts der extrem hohen Preise für Allzweck-KI-Beschleuniger erwarten die Gründer eine lukrative Marktnische.

Taalas zielt mit seinen Chips ausdrücklich auf Rechenzentren verspricht dort Kosten, die 20-mal niedriger liegen sollen als bei konventioneller GPU-Inferenz, bei einem Zehntel des Stromverbrauchs.

Ein mittelgroßes Reasoning-Modell auf Basis der gleichen HC1-Plattform soll im Frühjahr in den Taalas-Laboren eintreffen und kurz darauf als Inference-Service verfügbar werden.

Danach plant das Unternehmen, mit der zweiten Chipgeneration HC2 ein Frontier-LLM umzusetzen. Die HC2-Plattform soll standardisierte 4-Bit-Gleitkommaformate unterstützen, höhere Packungsdichte bieten und noch schneller arbeiten. Ein Deployment ist für den Winter vorgesehen.

Einordnung und offene Fragen

Die von Taalas genannten Leistungsdaten sind beeindruckend, lassen sich bislang aber nur eingeschränkt überprüfen. Die Benchmarks stammen aus hauseigenen Tests; unabhängige Messungen von Dritten liegen bisher nicht vor.

Auch ist unklar, wie sich die Qualitätseinbußen durch die aggressive Quantisierung in der Praxis auswirken – insbesondere bei komplexeren Aufgaben jenseits einfacher Chat-Konversationen. Ob das Konzept modellspezifischer Chips wirtschaftlich skaliert, wenn für jedes neue Modell eigenes Silizium gefertigt werden muss, bleibt ebenfalls abzuwarten.

Taalas geht es nicht um sogenannte „Edge AI“-Anwendungen, bei denen trainierte Modelle ohne Cloud-Anbindung direkt auf dem Gerät laufen. Das sind häufig Modelle für Spracherkennung, Sprachsteuerung, Objekterkennung in Videobildern für Überwachungskameras, Radar-Sensorauswertung oder Maschinenüberwachung durch Geräuschanalyse (Predictive Maintenance). Das ist die Domäne der Neural Processing Units (NPUs) mit derzeit 10 bis 90 Int8-Tops, die in verwirrender Vielfalt auf den Markt kommen: M5Stacks AI Pyramid-Pro, die Hailo-NPUs zum Nachrüsten des Raspberry Pi 5, Google Coral und die Embedded-Versionen von x86- und ARM-Prozessoren wie AMD Ryzen, Intel Panther Lake, Qualcomm Snapdragon, Mediatek Genio, Rockchip und etwa auch RISC-V-SoCs wie der SpacemiT K3. Auch die europäischen Automotive-Mikrocontroller-Spezialisten Infineon, STMicroelectronics und NXP offerieren alle Chips mit eingebauten NPUs, ebenso wie TI und Renesas.

Lesen Sie auch


(vza)



Source link

Weiterlesen

Beliebt