Entwicklung & Code
Java 25: Neue Features – nicht so bekannt, aber wichtig
Im September 2025 erscheint das OpenJDK 25 mit 18 Java Enhancement Proposals. Die bekannteren Funktionen haben wir uns bereits im vorangegangenen Post angeschaut. Jetzt werfen wir einen Blick auf die Themen, die bei den meisten Entwicklerinnen und Entwicklern etwas weniger Aufmerksamkeit erregen. Mit dabei sind Verbesserungen beim Profiling und Beobachten von laufenden Java-Anwendungen, beim Start und Warm-up, beim Speicherverbrauch und kleinere Änderungen bei Garbage Collectors sowie Erweiterungen bei der Unterstützung von Kryptografie.
Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen. Falk twittert unter @sippsack.
JEP 503 – Entfernung des 32-Bit-x86-Ports
Das Entfernen des Quellcodes und Build-Supports für den 32-Bit-x86-Port (nach Deprecation in JDK 24 via JEP 501) zielt darauf ab, neue Features nicht länger mit 32-Bit-Fallbacks bedienen zu müssen, alle 32-Bit-x86-Sonderpfade zu streichen und Build/Test-Infrastruktur zu vereinfachen. Nicht betroffen sind der 32-Bit-Support anderer Architekturen und frühere JDK-Releases. Der Pflegeaufwand stand in keinem Verhältnis zum Nutzen und das Entfernen beschleunigt die Weiterentwicklung (z. B. bei Loom, FFM API, Vector API, …).
(Bild: Playful Creatives/Adobe Stock))
Am 14. Oktober dreht sich bei der betterCode() Java 2025 alles um das für September geplante Java 25. Die von iX und dpunkt verlag ausgerichtete Online-Konferenz behandelt in sechs Vorträgen die wesentlichen Neuerungen. Eine Keynote von Adam Bien zu 30 Jahren Java rundet den Tag ab.
JEP 509 – Genauere CPU-Profile mit JFR (experimentell, nur für Linux)
Das Entwicklerteam hat den JDK Flight Recorder (JFR) so erweitert, dass er auf Linux den CPU-Zeit-Timer des Kernels nutzt und damit präzisere CPU-Profile erstellt. Und das auch dann, wenn Java-Code gerade native Bibliotheken ausführt. Bisher stützte sich JFR vor allem auf einen „Execution Sampler“, der in festen Echtzeit-Intervallen (z. B. alle 20 ms) Java-Stacks zieht. Dabei können Threads in nativem Code übersehen, Proben verpasst und gegebenenfalls nur ein Teil der Threads erfasst werden.
Mit CPU-Zeit-Profiling bildet JFR die tatsächlich verbrauchten CPU-Zyklen ab und vermeidet unsichere, interne Schnittstellen, wie sie manche externe Tools verwenden. Ein Sortieralgorithmus verbringt zum Beispiel seine gesamte Laufzeit auf der CPU und taucht entsprechend stark im CPU-Profil auf. Eine Methode, die meist auf Daten aus einem Socket wartet, beansprucht hingegen kaum CPU-Zeit und erscheint folglich nur geringfügig im Profil.
JEP 518 – Stabileres JFR-Stack-Sampling
Der JFR soll stabiler werden, indem er Java-Thread-Stacks nur noch an Safepoints traversiert und dabei den bekannten Safepoint-Bias so weit wie möglich reduziert. Bisher nahm der JFR in festen Intervallen (z. B. alle 20 ms) asynchron Samples auch außerhalb von Safepoints auf. Das erforderte Heuristiken zum Stack-Parsing, die ineffizient waren und im Fehlerfall sogar JVM-Crashes auslösen konnten (etwa bei gleichzeitigem Class-Unloading). Künftig wird die Profilerstellung der Wanduhrzeit (wall-clock time) weiter unterstützt, aber mit einem robusteren Verfahren, das Genauigkeit und Ausfallsicherheit besser ausbalanciert.
JEP 520 – Exaktes Methoden-Timing und -Tracing mit JFR (via Bytecode-Instrumentierung)
Dieses JEP erweitert den JDK Flight Recorder um eine Bytecode-Instrumentierung, die jeden ausgewählten Methodenaufruf exakt misst und mit Stacktrace aufzeichnet – im Gegensatz zu stichprobenbasiertem Profiling. Methoden lassen sich ohne Codeänderungen zielgenau per Kommandozeile, Konfigurationsdatei, jcmd oder JMX auswählen. Nicht vorgesehen sind das Aufzeichnen von Argumenten/Feldwerten, das Tracen nicht-bytecodierter Methoden (z. B. native
, abstract
) sowie das gleichzeitige Instrumentieren sehr vieler Methoden. In solchen Fällen bleibt Sampling der richtige Ansatz. Um lange Startzeiten zu analysieren, lassen sich statische Initialisierer ausgewählter Klassen gezielt tracen. So wird sichtbar, welche Initialisierung sich auf später verschieben lässt oder wo ein jüngst eingespielter Fix tatsächlich Laufzeit spart.
JEP 514 – AOT-Caches leichter erstellen
Dieses JEP vereinfacht das Erzeugen von Ahead-of-Time-Caches (AOT), die den Java-Start deutlich beschleunigen: Für gängige Fälle soll ein einziger Schritt genügen, der Trainingslauf und Cache-Erstellung kombiniert. Ziel ist es, die bislang nötige Zwei-Phasen-Prozedur (erst record
, dann create
mit separater AOT-Konfiguration) abzulösen – ohne an Ausdrucksstärke zu verlieren und ohne neue AOT-Optimierungen einzuführen. Ein Beispiel aus dem Status quo: Heute braucht man zwei java-Aufrufe und bleibt mit einer temporären *.aotconf-Datei zurück. Künftig entfällt dieser Ballast, was unter anderem Frameworks wie JRuby bei eigenen Trainingsläufen entgegenkommt. Für Spezialfälle bleiben die expliziten AOT-Modi und Konfigurationsoptionen weiterhin verfügbar.
JEP 515 – Schnellere Warm-up-Phase durch Profile aus dem AOT-Cache
Die JVM (Java Virtual Machine) kann jetzt beim Start Methodenausführungsprofile aus einem früheren Lauf laden, sodass der JIT direkt die voraussichtlich heißen Methoden kompiliert, statt zunächst Profile sammeln zu müssen. Die Profile werden in einem Training Run erzeugt und über den bestehenden AOT-Cache bereitgestellt. Dafür sind keine Codeänderungen und keine neuen Workflows nötig. Warm-up kostet heute Zeit, weil HotSpot erst während der Produktion herausfindet, welche Methoden es zu optimieren gilt. Verlagert man das Profiling in den Training Run, erreicht die Anwendung in Produktion schneller ihre Spitzenleistung. Ein Webdienst beispielsweise, der sonst erst nach einigen Minuten Profil-Sammeln voll performant ist, kann mit vorab aufgezeichneten Profilen schon beim Start die kritischen Request-Pfade kompilieren und so schneller unter Last reagieren.
JEP 470 – PEM-Encoding API (Preview)
Dieses JEP führt eine einfache API ein, um kryptografische Objekte — Schlüssel, Zertifikate und Sperrlisten — in das weit verbreitete PEM-Textformat (RFC 7468) zu kodieren und daraus wieder Objekte zu dekodieren. Sie unterstützt die Standardrepräsentationen PKCS#8 (Private Keys), X.509 (Public Keys, Zertifikate, CRLs) sowie PKCS#8 v2.0 (verschlüsselte Private Keys und asymmetrische Schlüssel). Bisher fehlte in Java eine komfortable PEM-API. Entwickler mussten Base64, Header/Footer-Parsing, Factory-Auswahl und Algorithmus-Erkennung selbst erledigen. Die neue Preview-API reduziert diesen Boilerplate deutlich.
JEP 510 – API für Key Derivation Functions (Finalisierung in JDK 25)
Dieses JEP finalisiert (unverändert gegenüber der Preview in JDK 24) eine API für Key Derivation Functions (KDFs), etwa HKDF (RFC 5869) und Argon2 (RFC 9106). Sie ermöglicht den Einsatz von KDFs in KEM/HPKE-Szenarien (z. B. ML-KEM, Hybrid Key Exchange in TLS 1.3), erlaubt PKCS#11-basierte Implementierungen und räumt auf, indem JDK-Komponenten wie TLS 1.3 und DHKEM auf die neue API statt auf interne HKDF-Logik umgestellt werden. Aus einem gemeinsamen Geheimnis (z. B. ECDH-Shared-Secret) und einem Salt lässt sich per HKDF deterministisch ein Satz Sitzungsschlüssel für Verschlüsselung und MAC ableiten. PBKDF1/2 wandern übrigens nicht in die neue API, sie bleiben wie bisher über SecretKeyFactory nutzbar.
JEP 519 – Kompakte Objekt-Header (Finalisierung in JDK 25)
Die kompakten Objekt-Header gelten mit dem Update nicht mehr als experimentell, sondern als offizielles Produktfeature. Sie gelten jedoch nicht als Standard-Layout. Seit ihrer Einführung in JDK 24 (JEP 450) haben sie sich in Stabilität und Performance bewährt – getestet mit der vollständigen JDK-Testsuche bei Oracle und in Hunderten von Amazon-Services (teils auf JDK 21/17 zurückportiert). Experimente zeigen deutliche Vorteile: bis zu 22 Prozent weniger Heap, 8 Prozent weniger CPU-Zeit, 15 Prozent weniger GCs (G1/Parallel), und ein hochparalleler JSON-Parser läuft zehn Prozent schneller. Damit verbessert der geringere Overhead pro Objekt die Speichernutzung und Cache-Lokalität, was spürbar Start-up und Durchsatz zugutekommt.
JEP 521 – Shenandoah (generational), Finalisierung in JDK 25
Der generationale Modus des Shenandoah-GC wechselt vom experimentellen in den Produktstatus (eingeführt als Experiment in JDK 24 via JEP 404). Der Standard bleibt unverändert, per Default nutzt Shenandoah weiterhin eine Generation. Die Umstufung basiert auf zahlreichen Stabilitäts- und Performance-Verbesserungen sowie umfangreichen Tests (u. a. DaCapo, SPECjbb2015, SPECjvm2008, Heapothesys); Anwender berichten von erfolgreichen Einsätzen unter Last. Zum Aktivieren des generationalen Modus ist -XX:+UnlockExperimentalVMOptions
nicht mehr nötig. Alle übrigen Optionen und Defaults bleiben gleich und bestehende Startskripte funktionieren weiter.
Java 25: stabil und durchdacht
Beim Blick auf die Vielzahl der sehr unterschiedlichen neuen und erneuerten Features zeigt sich, dass Java 25 auch wieder ein spannendes Release ist. Auch wenn für uns Entwickler auf den ersten Blick scheinbar gar nicht so viel Neues dabei ist. Vieles sind Wiedervorlagen aus früheren Preview-Versionen. Aber genau das zeigt, wie stabil und durchdacht sich Java weiterentwickelt. Und außerdem ist enorm viel unter der Haube passiert: von Performance-Optimierungen über Sicherheitsverbesserungen bis hin zu Weichenstellungen für die Zukunft, etwa in der Kryptografie und der Speicherverwaltung. Java bleibt damit eine moderne, leistungsfähige Plattform. Und im März 2026 steht mit dem OpenJDK 26 die nächste Version vor der Tür. Die Versionen 25 und 26 sind übrigens die einzigen, die mit der Jahreszahl ihrer Erscheinung übereinstimmen. Ab Java 27 müssen wir dann wieder überlegen, welche Version gerade aktuell ist.
Zum Vertiefen der hier genannten JEPs empfiehlt sich als Startpunkt die OpenJDK-25-Projektseite. Und es gibt natürlich auch eine ausführliche Liste aller Änderungen in den Release Notes. Zudem lohnt sich auch immer mal ein Blick auf die JEP-Drafts. Dort warten noch einige Themen auf ihre Veröffentlichung, wie Light-Weight JSON API, Null-Restricted and Nullable Types, Value Classes and Objects oder Integrity by Default. Uns Java-Entwicklern dürfte in Zukunft also nicht so schnell langweilig werden.
(mdo)
Entwicklung & Code
software-architektur.tv: Webperformance mit Lucas Dohmen und Lisa Maria Schäfer
In dieser Folge des Videocasts software-architektur.tv sprechen Lucas Dohmen und Lisa Maria Schäfer über Webperformance. Sie klären, was sich dahinter verbirgt und warum das Thema wichtig ist – und zwar für alle, die Webseiten entwickeln. Des Weiteren stellen sie Tools zum Messen der Webperformance vor und geben Impulse, wie man seine Website schneller machen kann.
Lisa Maria Schäfer malt dieses Mal keine Sketchnotes, da sie vor der Kamera ist.
Livestream am Freitag, 5. September
Die Ausstrahlung findet am Freitag, 5. September 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.
Weitere Informationen zur Folge finden sich auf der Videocast-Seite.
(mdo)
Entwicklung & Code
Microsoft gibt 6502 BASIC frei
Microsoft hat den Quellcode seines historischen 6502-BASIC-Interpreters aus dem Jahr 1976 erstmals offiziell als Open Source freigegeben und somit einen wichtigen Beitrag zur Bewahrung der Geschichte der Heimcomputer geleistet. Die Software wurde ursprünglich von Bill Gates und Ric Weiland für den beliebten 8-Bit-Prozessor MOS 6502 entwickelt. Später lag sie den einflussreichen Computern Commodore PET, VIC-20 und Commodore 64 zugrunde – Millionen von Nutzern lernten damit programmieren und prägen bis heute die Kulturszene rund ums Retro-Computing.
Die jetzt unter der MIT-Lizenz veröffentlichte Version 1.1 enthält laut Microsoft unter anderem Verbesserungen an der Speicherverwaltung, die 1978 gemeinsam mit Commodore-Entwickler John Feagans umgesetzt wurden. Damit handelt es sich um die Variante, die als BASIC V2 auf dem PET ausgeliefert wurde und bis heute in den ROM-Archiven von Computermuseen und Emulatoren lebt. Der 6955 Zeilen umfassende Assembly-Sourcecode steht ab sofort auf GitHub bereit – samt Unterstützung für verschiedene historische Systeme wie Apple II oder Commodore PET.
Mit an Bord sind außerdem die dokumentierten Easter Eggs von Bill Gates selbst. Denn in den Quellcodes von Microsoft 6502 BASIC sind mehrere versteckte Funktionen verborgen, darunter die berühmten Labels STORDO
und STORD0
, wie Bill Gates selbst 2010 bestätigte. Besonders bekannt ist das WAIT 6502,1
-Kommando, das auf einem Commodore PET mit BASIC V2 das Wort MICROSOFT!
auf dem Bildschirm erscheinen lässt – das versteckte Markenzeichen hatte Bill Gates gezielt eingebaut.
Microsoft betont mit der Veröffentlichung die historische Bedeutung des BASIC-Interpreters für die eigenen Anfänge. Gleichzeitig verweist der Konzern in seiner Ankündigung darauf, dass sich die Community – von Museumsarchiven bis hin zu modernen FPGA- und Emulator-Projekten – schon seit Jahrzehnten für dessen Erhalt und praktische Anwendung eingesetzt hat. 2020 hatte Microsoft bereits den GW-BASIC-Interpreter als Open Source veröffentlicht, der aus dem Jahr 1983 stammt und für IBM-kompatible PCs beziehungsweise MS-DOS zum Einsatz kam.
(fo)
Entwicklung & Code
Künstliche Neuronale Netze im Überblick 7: Rekursive neuronale Netze
Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente. Der siebte Teil widmet sich rekursiven neuronalen Netzen, nachdem der sechste Teil der Serie Convolutional Neural Networks vorgestellt hat.
Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.
Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.
Rekursive neuronale Netze sind für die Verarbeitung sequenzieller Daten ausgelegt, indem sie einen versteckten Zustand aufrechterhalten, der sich im Laufe der Zeit weiterentwickelt. Im Gegensatz zu Feedforward-Netzwerken, die davon ausgehen, dass jede Eingabe unabhängig von allen anderen ist, ermöglichen rekursive Netzwerke das Speichern von Informationen über Zeiträume hinweg. Bei jedem Schritt t empfängt eine rekurrente Zelle sowohl den neuen Eingabevektor xₜ als auch den vorherigen versteckten Zustand hₜ₋₁. Die Zelle berechnet einen neuen versteckten Zustand hₜ gemäß einer gelernten Transformation und erzeugt (optional) eine Ausgabe yₜ.
In ihrer einfachsten Form berechnet eine Vanilla-RNN-Zelle einen Präaktivierungsvektor zₜ als Summe einer Eingabetransformation und einer versteckten Zustandstransformation plus einer Verzerrung:
zₜ = Wₓ · xₜ + Wₕ · hₜ₋₁ + b
Der neue Zustand entsteht durch elementweise Anwendung einer nicht linearen Aktivierung σ:
hₜ = σ(zₜ)
Wenn bei jedem Zeitschritt eine Ausgabe yₜ erforderlich ist, kann eine Ausleseschicht hinzugefügt werden:
yₜ = V · hₜ + c
wobei V und c eine Ausgabegewichtungsmatrix und ein Bias-Vektor sind.
In PyTorch kapselt die Klasse torch.nn.RNN
dieses Verhalten und verarbeitet das Stapeln mehrerer Schichten und Batches nahtlos. Das folgende Beispiel zeigt, wie man eine einlagige RNN-Zelle erstellt, ihr einen Stapel von Sequenzen zuführt und den endgültigen versteckten Zustand extrahiert:
import torch
import torch.nn as nn
# Angenommen, wir haben Sequenzen der Länge 100, jedes Element ist ein 20-dimensionaler Vektor,
# und wir verarbeiten sie in Batches der Größe 16.
seq_len, batch_size, input_size = 100, 16, 20
hidden_size = 50
# Erstellen Sie einen zufälligen Stapel von Eingabesequenzen: Form (seq_len, batch_size, input_size)
inputs = torch.randn(seq_len, batch_size, input_size)
# Instanziieren Sie ein einlagiges RNN mit tanh-Aktivierung (Standard)
rnn = nn.RNN(input_size=input_size,
hidden_size=hidden_size,
num_layers=1,
nonlinearity='tanh',
batch_first=False)
# Initialisiere den versteckten Zustand: Form (Anzahl_Schichten, Batchgröße, versteckte Größe)
h0 = torch.zeros(1, batch_size, hidden_size)
# Vorwärtspropagierung durch das RNN
outputs, hn = rnn(inputs, h0)
# `outputs` hat die Form (seq_len, batch_size, hidden_size)
# `hn` ist der versteckte Zustand beim letzten Zeitschritt, Form (1, batch_size, hidden_size)
Jede Zeile dieses Ausschnitts hat eine klare Aufgabe. Durch das Erstellen von Eingaben simuliert man ein Batch von Zeitreihendaten. Das RNN-Modul weist zwei Parametermatrizen zu: eine mit der Form (hidden_size, input_size
) für Wₓ und eine mit der Form (hidden_size, hidden_size
) für Wₕ sowie einen Bias-Vektor der Länge hidden_size
. Beim Aufrufen des Moduls für Eingaben und den Anfangszustand h0 durchläuft es die 100 Zeitschritte und berechnet bei jedem Schritt die Rekursionsbeziehung. Der Ausgabetensor sammelt alle Zwischenzustände, während hn nur den letzten zurückgibt.
Obwohl Vanilla-RNNs konzeptionell einfach sind, haben sie Schwierigkeiten, langfristige Abhängigkeiten zu lernen, da über viele Zeitschritte zurückfließende Gradienten dazu neigen, zu verschwinden oder zu explodieren. Um das abzumildern, führen Gated Recurrent Units wie LSTM und GRU interne Gates ein, die steuern, wie stark die Eingabe und der vorherige Zustand den neuen Zustand beeinflussen sollen.
Die LSTM-Zelle (Long Short-Term Memory) verwaltet sowohl einen versteckten Zustand hₜ als auch einen Zellzustand cₜ. Sie verwendet drei Gates – Forget Gate fₜ, Input Gate iₜ und Output Gate oₜ –, die als Sigmoid-Aktivierungen berechnet werden, sowie eine Kandidaten-Zellaktualisierung ĉₜ, die sich mit einer Tanh-Aktivierung berechnen lässt. Konkret:
fₜ = σ( W_f · xₜ + U_f · hₜ₋₁ + b_f )
iₜ = σ( W_i · xₜ + U_i · hₜ₋₁ + b_i )
oₜ = σ( W_o · xₜ + U_o · hₜ₋₁ + b_o )
ĉₜ = tanh( W_c · xₜ + U_c · hₜ₋₁ + b_c )
Der Zellzustand wird dann durch Kombination des vorherigen Zellzustands und des Kandidaten aktualisiert, gewichtet durch die Vergessens- und Eingangsgatter:
cₜ = fₜ * cₜ₋₁ + iₜ * ĉₜ
Schließlich erstellt das System den neuen versteckten Zustand, indem es das Ausgangs-Gate auf die Nichtlinearität des Zellzustands anwendet:
hₜ = oₜ * tanh(cₜ)
PyTorchs torch.nn.LSTM
kapselt all diese Berechnungen unter der Haube. Folgender Code zeigt ein Beispiel für eine Reihe von Sequenzen:
import torch
import torch.nn as nn
# Sequenzparameter wie zuvor
seq_len, batch_size, input_size = 100, 16, 20
hidden_size, num_layers = 50, 2
# Zufälliger Eingabebatch
inputs = torch.randn(seq_len, batch_size, input_size)
# Instanziieren eines zweischichtigen LSTM
lstm = nn.LSTM(input_size=input_size,
hidden_size=hidden_size,
num_layers=num_layers,
batch_first=False)
# Initialisiere versteckte und Zellzustände: jeweils mit der Form (Anzahl_Schichten, Batchgröße, versteckte Größe)
h0 = torch.zeros(num_layers, batch_size, hidden_size)
c0 = torch.zeros(num_layers, batch_size, hidden_size)
# Vorwärtsdurchlauf durch das LSTM
outputs, (hn, cn) = lstm(inputs, (h0, c0))
# `outputs` hat die Form (seq_len, batch_size, hidden_size)
# `hn` und `cn` haben jeweils die Form (num_layers, batch_size, hidden_size)
Die Gated Recurrent Unit (GRU) vereinfacht das LSTM, indem sie die Vergessens- und Eingangsgatter zu einem einzigen Aktualisierungsgatter zₜ kombiniert und die Zell- und versteckten Zustände zusammenführt. Die Gleichungen lauten:
zₜ = σ( W_z · xₜ + U_z · hₜ₋₁ + b_z )
rₜ = σ( W_r · xₜ + U_r · hₜ₋₁ + b_r )
ħₜ = tanh( W · xₜ + U · ( rₜ * hₜ₋₁ ) + b )
hₜ = (1 − zₜ) * hₜ₋₁ + zₜ * ħₜ
In PyTorch bietet torch.nn.GRU
diese Funktionalität mit derselben Schnittstelle wie nn.LSTM
, außer dass nur die versteckten Zustände zurückgegeben werden.
Bei der Arbeit mit Sequenzen variabler Länge benötigt man häufig torch.nn.utils.rnn.pack_padded_sequence
und pad_packed_sequence
, um Sequenzen effizient im Batch zu verarbeiten, ohne Rechenleistung für das Auffüllen von Tokens zu verschwenden.
Rekursive Netzwerke eignen sich hervorragend für Aufgaben wie Sprachmodellierung, Zeitreihenprognosen und Sequenz-zu-Sequenz-Übersetzungen, wurden jedoch in vielen Anwendungsbereichen von aufmerksamkeitsbasierten Modellen übertroffen.
Zunächst widmet sich der nächste Teil dieser Serie jedoch der Kombination aus konvolutionalen und rekursiven Schichten, um Daten mit sowohl räumlicher als auch zeitlicher Struktur zu verarbeiten. Bei der Videoklassifizierung kann ein Convolutional Neural Network beispielsweise Merkmale auf Frame-Ebene extrahieren, die dann in ein LSTM eingespeist werden, um Bewegungsdynamiken zu erfassen.
(rme)
-
Datenschutz & Sicherheitvor 3 Monaten
Geschichten aus dem DSC-Beirat: Einreisebeschränkungen und Zugriffsschranken
-
UX/UI & Webdesignvor 2 Wochen
Der ultimative Guide für eine unvergessliche Customer Experience
-
Apps & Mobile Entwicklungvor 3 Monaten
Metal Gear Solid Δ: Snake Eater: Ein Multiplayer-Modus für Fans von Versteckenspielen
-
Online Marketing & SEOvor 3 Monaten
TikTok trackt CO₂ von Ads – und Mitarbeitende intern mit Ratings
-
UX/UI & Webdesignvor 6 Tagen
Adobe Firefly Boards › PAGE online
-
Social Mediavor 2 Wochen
Relatable, relevant, viral? Wer heute auf Social Media zum Vorbild wird – und warum das für Marken (k)eine gute Nachricht ist
-
Entwicklung & Codevor 2 Wochen
Posit stellt Positron vor: Neue IDE für Data Science mit Python und R
-
Digital Business & Startupsvor 2 Monaten
10.000 Euro Tickets? Kann man machen – aber nur mit diesem Trick