Connect with us

Entwicklung & Code

Neuerungen in C++26: Datenparallele Datentypen (SIMD)


Die SIMD-Bibliothek bietet in C++26 portable Typen zur expliziten Angabe von Datenparallelität und zur Strukturierung von Daten für einen effizienteren SIMD-Zugriff. Bevor wir uns im Detail mit der neuen Bibliothek befassen, möchte ich kurz ein paar allgemeine Anmerkungen zu SIMD (Single Instruction, Multiple Data) voranschicken.


Rainer Grimm

Rainer Grimm

Rainer Grimm ist seit vielen Jahren als Softwarearchitekt, Team- und Schulungsleiter tätig. Er schreibt gerne Artikel zu den Programmiersprachen C++, Python und Haskell, spricht aber auch gerne und häufig auf Fachkonferenzen. Auf seinem Blog Modernes C++ beschäftigt er sich intensiv mit seiner Leidenschaft C++.

SIMD – Single Instruction, Multiple Data

Vektorisierung bezieht sich auf die SIMD-Erweiterungen (Single Instruction, Multiple Data) des Befehlssatzes moderner Prozessoren. SIMD ermöglicht es dem Prozessor, eine Operation parallel auf mehrere Daten anzuwenden.

Ein einfaches Beispiel: Ob ein Algorithmus parallel und vektorisiert ausgeführt wird, hängt von vielen Faktoren ab – unter anderem davon, ob die CPU und das Betriebssystem SIMD-Befehle unterstützen. Außerdem kommt es auf den Compiler und den Optimierungsgrad an, der zum Kompilieren des Codes eingesetzt wird.


// SIMD.cpp

const int SIZE= 8;

int vec[]={1,2,3,4,5,6,7,8};
int res[SIZE]={0,};

int main(){
  for (int i= 0; i < SIZE; ++i) {
    res[i]= vec[i]+5; // (1)
  }
}


Zeile 1 ist die Schlüsselzeile in dem kleinen Programm. Dank des Compiler Explorers ist es recht einfach, die Assemblerbefehle für Clang 3.6 mit und ohne maximale Optimierung (-O3) zu generieren.

Obwohl meine Zeit, in der ich mit Assemblerbefehlen herumgespielt habe, lange vorbei ist, ist es offensichtlich, dass alles sequenziell ausgeführt wird:



(Bild: Rainer Grimm)

Mit maximaler Optimierung

Durch die Verwendung der maximalen Optimierung erhalte ich Befehle, die parallel auf mehreren Datensätzen ausgeführt werden:



(Bild: Rainer Grimm)

Die Move-Operation (movdqa) und die Add-Operation (paddd) verwenden die speziellen Register xmm0 und xmm1. Beide Register sind sogenannte SSE-Register mit einer Breite von 128 Bit. Damit können 4 ints auf einmal verarbeitet werden. SSE steht für Streaming SIMD Extensions. Leider sind Vektorbefehle stark von der eingesetzten Architektur abhängig. Weder die Befehle noch die Registerbreiten sind einheitlich.

Moderne Intel-Architekturen unterstützen meist AVX2 oder sogar AVX-512. Dies ermöglicht 256-Bit- oder 512-Bit-Operationen. Damit können 8 oder 16 ints parallel verarbeitet werden. AVX steht für Advanced Vector Extension.

Genau hier kommen die neuen datenparallelen Datentypen der Bibliothek ins Spiel, die eine einheitliche Schnittstelle zu Vektorbefehlen bieten.

Datenparallele Typen (SIMD)

Bevor ich mich mit der neuen Bibliothek beschäftige, sind einige Definitionen erforderlich. Diese Definitionen beziehen sich auf den Proposal P1928R15. Insgesamt umfasst die neue Bibliothek sechs Proposals.


Cpp SIMD

Cpp SIMD

(Bild: Rainer Grimm)

Die Menge der vektorisierbaren Typen umfasst alle Standard-Ganzzahltypen, Zeichentypen sowie die Typen float und double. Darüber hinaus sind std::float16_t, std::float32_t und std::float64_t vektorisierbare Typen, sofern sie definiert sind.

Der Begriff datenparallel bezieht sich auf alle aktivierten Spezialisierungen der Klassen-Templates basic_simd und basic_simd_mask. Ein datenparalleles Objekt ist ein Objekt vom datenparallelen Typ.

Ein datenparalleler Typ besteht aus einem oder mehreren Elementen eines zugrunde liegenden vektorisierbaren Typs, der als Elementtyp bezeichnet wird. Die Anzahl der Elemente ist für jeden datenparallelen Typ eine Konstante und wird als Breite dieses Typs bezeichnet. Die Elemente in einem datenparallelen Typ werden von 0 bis Breite −1 indiziert.

Eine elementweise Operation wendet eine bestimmte Operation auf die Elemente eines oder mehrerer datenparalleler Objekte an. Jede solche Anwendung ist in Bezug auf die anderen nicht sequenziell. Eine unäre elementweise Operation ist eine elementweise Operation, die eine unäre Operation auf jedes Element eines datenparallelen Objekts anwendet. Eine binäre elementweise Operation ist eine elementweise Operation, die eine binäre Operation auf entsprechende Elemente zweier datenparallelisierter Objekte anwendet.

Nach so viel Theorie möchte ich nun ein kleines Beispiel zeigen. Es stammt von Matthias Kretz, Autor des Proposals P1928R15. Das Beispiel aus seiner Präsentation auf der CppCon 2023 zeigt eine Funktion f, die einen Vektor entgegennimmt und dessen Elemente auf ihre Sinuswerte abbildet:


 void f(std::vector& data) {
    using floatv = std::simd;
    for (auto it = data.begin(); it < data.end(); it += floatv::size()) {
        floatv v(it);
        v = std::sin(v);
        v.copy_to(it);
    }
}


Die Funktion f nimmt einen Vektor von Floats (data) als Referenz. Sie definiert floatv als SIMD-Vektor von Floats unter Verwendung von std::simd. f durchläuft den Vektor in Blöcken, wobei jeder Block die Größe des SIMD-Vektors hat.

Für jeden Block gilt:

  • Lädt den Block in einen SIMD-Vektor (floatv v(it);).
  • Wendet die Sinusfunktion gleichzeitig auf alle Elemente im SIMD-Vektor an (v = std::sin(v);).
  • Schreibt die Ergebnisse zurück in den ursprünglichen Vektor (v.copy_to(it);).

Die Behandlung von SIMD-Anweisungen wird besonders elegant, wenn der Proposal P0350R4 in C++26 implementiert wird. SIMD kann dann beispielsweise als neue Execution Policy in Algorithmen verwendet werden:


void f(std::vector& data) {
    std::for_each(std::execution::simd, data.begin(), data.end(), [](auto& v) {
        v = std::sin(v);
    });
}


Wie geht es weiter?

In meinem nächsten Artikel werde ich mich näher mit der neuen SIMD-Bibliothek befassen.


(map)



Source link

Verwandte Themen:
Weiterlesen
Kommentar schreiben

Leave a Reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Entwicklung & Code

Git 2.50 kickt recursive raus – ORT regelt ab jetzt die Merges


Mit Git 2.50 hat das Open-Source-Projekt unter der Leitung von Junio C Hamano zahlreiche Änderungen veröffentlicht, die vor allem die Verwaltung großer Repositorys betreffen. Die neuen Funktionen und Anpassungen stammen in dieser Version von insgesamt 98 Mitwirkenden.

Git setzt mit dem Update ausschließlich auf die moderne Merge-Engine ORT, die bereits in Version 2.33 vorgestellt wurde. Den bisherigen Standard recursive hat das Team aus dem Quellcode entfernt. ORT steht für „Ostensibly Recursive’s Twin“ und ist eine komplette Neuentwicklung des bisherigen Merge-Backends. Sie soll laut GitHub-Blogbeitrag schneller, robuster und besser wartbar sein. Mit dem neuen --quiet-Modus des Befehls merge-tree lässt sich laut den Entwicklern prüfen, ob ein Merge möglich ist, ohne dabei neue Objekte im Repository zu erzeugen.

Cruft-Packs effizienter verwalten

Für Repositorys mit vielen nicht mehr referenzierten Objekten bringt Git 2.50 eine neuartige Verwaltung durch die Option --combine-cruft-below-size. Damit sollen sich kleinere Cruft-Packs gezielt zu größeren zusammenführen lassen. Gleichzeitig wurde das Verhalten von --max-cruft-size überarbeitet und klarer definiert. Einen Bug, der verhinderte, dass bestimmte Objekte in mehreren Cruft-Packs korrekt aktualisiert wurden, behebt das Update ebenfalls.

Reachability-Bitmaps inkrementell nutzbar

Git 2.50 führt Unterstützung für Reachability-Bitmaps in inkrementellen Multi-Pack-Indizes ein. Diese Änderung soll es ermöglichen, neue Bitmaps schrittweise zu ergänzen, anstatt bestehende vollständig neu schreiben zu müssen. Gerade bei sehr großen Repositorys könnte das die Performance verbessern. Die Funktion gilt derzeit noch als experimentell.

Weitere kleinere Neuerungen

  • Mit git reflog delete steht ein direkter Befehl zum Löschen eines kompletten Reflogs bereit
  • git maintenance kann zusätzliche Aufgaben übernehmen, darunter worktree-prune und reflog-expire
  • git cat-file soll Objekte nun auch direkt nach Typ filtern können
  • git add -p und git add -i funktionieren laut Changelog jetzt besser in Sparse Checkouts, ohne den Index vollständig zu laden

Git wird seit seiner Entstehung 2005 von einer aktiven Entwicklergemeinschaft betreut und ursprünglich von Linus Torvalds initiiert. Weitere Details zum Release von Git 2.50 finden sich im Beitrag auf dem GitHub-Blog.


(mdo)



Source link

Weiterlesen

Entwicklung & Code

Wie KI die Fähigkeiten von Entwicklerinnen und Entwicklern untergräbt


Mir ist vor Kurzem etwas passiert, das ich sehr erschreckend fand. Ich wurde gebeten, einen Pull Request zu reviewen, und bin dabei auf eine Codezeile gestoßen, die ich nicht verstanden habe und die für mein Verständnis keinen wirklichen Sinn ergeben hat. Da ich kein Freund davon bin, in einem Review vorschnell mit einem harschen

„Das ist falsch!“

zu reagieren, sondern stets versuche, auch die Option in Betracht zu ziehen, dass ich vielleicht etwas missverstanden habe, dass mir eventuell der Kontext fehlt oder dass ich noch nicht das gesamte Bild überblicke, habe ich den Entwickler, der diesen Pull Request verfasst hat, gefragt, was es mit dieser Zeile auf sich habe. Ich würde sie nicht verstehen. Die Antwort lautete:

„Das weiß ich leider auch nicht, ich habe das nicht so wirklich verstanden, aber ChatGPT hat gesagt, dass das so sein muss.“

Ich war sprachlos.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Meiner Meinung nach sollte man niemals und unter keinen Umständen Code als „fertig“ deklarieren, den man nicht verstanden hat. Ich habe mich über diesen Vorfall dann mit einer Reihe von befreundeten Entwicklerinnen und Entwicklern ausgetauscht. Das Erschreckende ist: Die meisten von ihnen haben diese Erfahrung auch schon gemacht. Es handelt sich also nicht um einen Einzelfall, sondern das scheint inzwischen eine durchaus gängige Normalität zu sein. Und das ist ein Problem, auf ganz vielen verschiedenen Ebenen.

Kein Mehrwert gegenüber der KI

Fangen wir mit dem offensichtlichsten Punkt an: Wenn Sie als Entwicklerin oder als Entwickler nicht in der Lage sind, Ihre Arbeit und Ihre Ergebnisse zu erklären, weil Sie Ihre Arbeit von einer KI erledigen lassen und mehr oder weniger einfach nur das durchwinken, was Ihnen die KI generiert hat, dann stellt sich die Frage: Welchen Mehrwert liefern Sie?

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

KI zerstört Deine Intelligenz // deutsch

Anders formuliert: Sie sind deutlich teurer als die KI. Wenn Ihre gesamte Leistung lediglich darin besteht, einen (hoffentlich) passenden Prompt zu formulieren und dann das KI-generierte Ergebnis unhinterfragt und unverstanden einfach nur weiterzugeben, dann wäre es objektiv betrachtet günstiger und auch effizienter, die Aufgabe direkt der KI zu geben. Denn auch Ihnen muss zunächst jemand die Aufgabe erklären, zum Beispiel in Form einer Anforderung. Das ist aber letztlich nichts anderes als ein Prompt, und diesen könnte man theoretisch auch direkt an die KI übergeben und das Ergebnis 1:1 übernehmen. Das ginge nicht nur deutlich schneller, sondern wäre vor allem deutlich günstiger. Die Frage ist also: Womit ist Ihr Job gerechtfertigt?

Natürlich kann man nun einwenden:

„Entwicklerinnen und Entwickler sehen sich das Ergebnis aber noch einmal genau an und validieren es, und damit ist das Ergebnis am Ende dann viel besser!“

Der Punkt dabei ist nur: Genau das erfordert, dass man verstanden hat und nachvollziehen kann, was die KI generiert hat. Und genau das war im besagten Fall eben nicht gegeben. Insofern stellt sich durchaus die Frage: Wenn Sie regelmäßig so arbeiten, untergraben Sie damit nicht langfristig Ihren eigenen Job? Das ist vermutlich nicht in Ihrem Interesse.

Papa, darf ich Instagram haben?

Wie reagiert man auf einen solchen Vorfall? Eine Möglichkeit wäre, pauschal den Einsatz von KI zu verbieten. Das Problem dabei ist allerdings, dass Verbote in der Regel wenig bis gar nichts nützen. Das ist genauso wie bei einem Teenager, der fragt, ob er einen Instagram-Account haben dürfe, und Sie als Elternteil sagen dann „nein“.

Das Ergebnis ist mit hoher Wahrscheinlichkeit nicht, dass der Teenager dann keinen Instagram-Account haben wird, sondern dass er relativ bald stattdessen heimlich einen erstellt. Das kann natürlich nicht das Argument sein, um als Eltern allem einfach zuzustimmen, und letztlich muss den richtigen Weg hierfür auch jede Familie für sich entscheiden, aber ich persönlich denke mir: Es ist durchaus ein Vertrauensbeweis und etwas Besonderes, wenn Ihr Kind Sie das fragt. Vielleicht ist es sinnvoll(er), das Positive zu sehen und zu versuchen, gemeinsam einen Weg zu finden, statt ein pauschales Verbot auszusprechen, das ohnehin nicht greift.

So ähnlich ist es auch, wenn man in einem Unternehmen versucht, künstliche Intelligenz zu verbieten. Das kann man machen – aber es wird vermutlich nicht besonders gut funktionieren, weil die Versuchung, sich das Leben leichter zu machen, sehr groß ist.

KI ist verführerisch

Damit kommen wir zu dem Punkt, warum so viele Entwicklerinnen und Entwickler überhaupt auf künstliche Intelligenz zurückgreifen. Denn eigentlich müsste man annehmen, dass, wenn man das zu lösende Problem verstanden hat, es in der Mehrzahl der Fälle nicht so schwierig sein dürfte, den passenden Code selbst zu schreiben. Warum macht man das also?

Künstliche Intelligenz macht das Leben leichter, zumindest auf den ersten Blick. Man muss nicht mehr so viel über das Problem und die Lösung nachdenken, man kann mögliche Stolpersteine umgehen und mit weniger Aufwand zu einem guten Ergebnis kommen. Warum also sollte man das nicht nutzen?

Das lässt sich recht einfach beantworten, wenn man sich fragt, warum wir Kindern in der Grundschule nicht einfach einen Taschenrechner in die Hand drücken, sondern ihnen mühsam zunächst schriftliches Addieren und andere Grundrechenarten beibringen. Der Taschenrechner wird üblicherweise erst am Ende der Unterstufe oder am Anfang der Mittelstufe eingeführt, wenn das Kind die Grundrechenarten von Hand beherrscht.

Würden Sie es für eine gute Idee halten, wenn wir Kindern nun nicht mehr das Rechnen an sich, sondern nur noch das Bedienen eines Taschenrechners beibringen würden? Vermutlich nicht. Denn ein gewisses Grundverständnis ist zwingend erforderlich, um später komplexere Probleme lösen zu können.

Wissen …

Der Taschenrechner in der ersten Klasse ist jedoch nur ein Beispiel von vielen. Man könnte auch sagen: 99 Prozent der alltäglichen Kommunikation findet über gesprochene Sprache statt. Eigentlich muss man dafür auch nicht mehr unbedingt lesen und schreiben lernen. Das mag provokant klingen, aber wenn Sie sich fragen, wo Sie in Ihrem Alltag wirklich auf geschriebene Sprache angewiesen sind, dann ist das nicht allzu häufig der Fall. Alexa liest die Nachrichten vor, Tomaten und Gurken können Sie im Supermarkt vermutlich auch dann voneinander unterscheiden, wenn Sie das zugehörige Schild nicht lesen können, und in der Apotheke geben Sie ohnehin das Rezept ab, das Ihnen Ihre Ärztin oder Ihr Arzt ausgestellt hat. Wozu also noch lesen und schreiben lernen?

Wie gesagt: Das ist ein provokantes Beispiel. Der Punkt ist jedoch: Wenn wir grundlegende Fähigkeiten entweder nie erlernen oder sie durch Nichtnutzung wieder verlernen, fehlt uns die Basis für komplexeres Denken. Und genauso ist das beim Entwickeln: Wenn Sie nie gelernt haben – oder zunehmend verlernen – Probleme selbst zu analysieren, Fehler zu suchen, unterschiedliche Lösungsstrategien zu entwickeln, Vor- und Nachteile abzuwägen, Dinge auszuprobieren, kurz: Erfahrung zu sammeln, dann werden Sie nie an Ihren Aufgaben wachsen. Dann sind Sie nämlich dauerhaft darauf angewiesen, dass jemand anders Ihnen sagt, wie Sie etwas besser lösen sollten.

… und Erfahrung

Ich kann mir denken, welches Gegenargument an dieser Stelle kommen wird:

„Das kann mir doch aber auch die KI sagen. Ich muss nur fragen.“

Das Problem daran: Sie wissen nicht, was und wann Sie fragen müssen, weil Sie gar nicht wissen, was in der jeweiligen Situation relevant ist und worauf Sie achten müssten. Um ein Beispiel zu nennen: Wenn Sie eine Datei speichern möchten, und dabei sicherstellen wollen, dass sie auch dann vollständig geschrieben wird, wenn beispielsweise der Strom ausfällt, dann dürfen Sie die Datei nicht einfach so schreiben. Sonst haben Sie möglicherweise eine halbe Datei.

Stattdessen müssen Sie den Inhalt zunächst in eine temporäre Datei schreiben und diese dann umbenennen. Das Umbenennen ist nämlich (meistens) ein atomarer Vorgang. Unter macOS und Linux funktioniert das allerdings wiederum etwas anders als unter Windows. Wenn Sie dieses Problem lösen sollen, müssen Sie also all das wissen. Wenn Sie das nicht wissen, weil Sie nie gelernt haben, wie SSDs funktionieren, was Blöcke sind, wie ein Dateisystem funktioniert, was „atomar“ bedeutet, was eine Transaktion ist, welchen Einfluss Partitionen haben, was der POSIX-Standard ist, und so weiter – dann werden Sie den Vorschlag der KI auch nicht hinterfragen, sondern ihn direkt übernehmen. Und genau das ist das Problem.

KI funktioniert, bis sie nicht mehr funktioniert

Was Sie in solchen Situationen brauchen, ist also nicht nur Wissen, sondern vor allem auch Erfahrung. Wissen kann man nachschlagen. Erfahrung hingegen kann man nicht nachschlagen – die muss man machen: Sie müssen Fehler machen, Sie müssen herausfinden, wo die Ursachen liegen und wie man sie behebt, und das kostet Zeit. Wenn Sie das nicht tun, verlernen Sie – oder lernen gar nicht erst –, wie man komplexe Probleme löst.

Insofern fördert der Einsatz von künstlicher Intelligenz ein sehr oberflächliches Entwickeln: Auf den ersten Blick scheint alles korrekt. Wenn Sie kein tieferes Wissen haben, denken Sie schnell, dass alles zu passen scheint. Aber Sie können es nicht wirklich beurteilen. Sie erkennen nicht die Konsequenzen, kennen keine Alternativen, denken nicht aktiv über Codequalität, Performance oder Architektur nach, und Sie prüfen nichts mehr, weil Sie sich daran gewöhnt haben, dass die KI in der Regel richtig liegt. Doch KI-generierter Code – sofern er nicht trivial ist – enthält gerne subtile Fehler.

Das Beispiel mit dem atomaren Schreiben ist mein üblicher Test: Kein Sprachmodell, das ich bisher ausprobiert habe, liefert auf Anhieb eine korrekte Lösung – im Gegenteil. Und hakt man nach, nähert es sich einer korrekten Lösung nach und nach an, bleibt aber erschreckend lange fehlerhaft. Und Sie merken das nicht, wenn Sie die Grundlagen nicht selbst verstanden haben.

Auf dem Weg in eine Zwei-Klassen-Gesellschaft

Kurz gesagt: Wissen und Erfahrung schwinden – und damit auch Ihre Fähigkeit, echte Probleme zu lösen. KI macht Sie dümmer. Und je mehr Sie sie einsetzen, desto schneller tritt dieser Effekt ein.

Damit steuern wir auf eine Zwei-Klassen-Gesellschaft zu: Es gibt Entwicklerinnen und Entwickler, die den steinigen Weg gehen, langsam vorankommen, die Grundlagen verstehen und sich mit Details befassen. Und es gibt jene, die sich auf KI verlassen. Letztere werden aber langfristig keinen Erfolg haben, denn Sie sind nicht in der Lage, einen echten Mehrwert zu leisten. Ihr Job kann über kurz oder lang automatisiert werden.

Das ist überraschenderweise kein neues Phänomen. Schon vor KI gab es diese Unterschiede. Ich habe in einer Zeit programmieren gelernt, in der es (für mich) kein Internet gab. Daher war ich auf Bücher, Zeitschriften und vor allem auf logisches Denken angewiesen. Diese Zeit war mühsam, aber ich bin dankbar dafür. Sie hat mir beigebracht, ein Problem im Kern verstehen zu wollen – oder zu müssen.

Wer schon einmal mit mir im Pair Programming gearbeitet hat, weiß, dass ich ständig frage:

„Warum ist das so?“

Ich will verstehen, bevor ich handle. Aber ich habe oft das Gefühl, damit allein zu sein.

Bei der Fehlersuche beobachte ich zum Beispiel oft, dass viele Entwicklerinnen und Entwickler nicht gründlich den Code und die Fehlermeldung lesen und nachdenken, sondern mehr oder weniger blind und wahllos herumprobieren, was ihnen naheliegend erscheint. Ich hingegen analysiere den Code und finde so meist schnell die Ursache. Nicht, weil ich besonders klug bin, sondern weil ich mich auf das Problem einlasse und versuche, es zu durchdringen.

Tiefes Wissen ist selten

Viele machen sich meiner Meinung nach dabei das Leben zu leicht. Sie verlassen sich auf Assistenten, Frameworks – und heute eben auf KI, ohne sich mit den Grundlagen zu befassen. Das hat in den 1990er-Jahren schon nicht funktioniert, und heute funktioniert es immer noch nicht. Tiefes Wissen ist selten und wird durch KI noch seltener. KI verstärkt die Spaltung. Es gibt eine kleine Elite, die Systeme versteht. Und eine große Masse, die KI-Code validiert, ohne ihn zu verstehen. Diese Masse erlebt aktuell die Illusion von Beschleunigung und Befähigung, doch in Wahrheit schaufelt sie sich ihr eigenes Grab.

Unternehmen glauben, sie könnten künftig ohne Entwicklerinnen und Entwickler auskommen – bis irgendwann niemand mehr da ist, der komplexe Probleme lösen und die KI noch hinterfragen kann. Die wenigen, die das dann noch können, werden sehr, sehr teuer sein. Und dann ist das Gejammer groß …

Was tun?

Ich hatte eingangs gefragt, wie man mit dem Thema umgehen sollte. Ein Verbot wird nicht funktionieren, KI lässt sich nicht mehr aufhalten. Die Frage lautet also vielmehr: Wie arrangiert man sich mit KI?

Ich glaube, die Lösung muss sein: Nutzen Sie KI als Werkzeug, aber behalten Sie die Kontrolle. Die KI darf keine Entscheidung treffen, die Sie nicht auch selbst hätten treffen können. Wenn Sie die KI nicht mehr hinterfragen können, dann haben Sie die Kontrolle verloren. Meine persönliche Faustregel lautet daher: Wenn Sie es nicht selbst schreiben könnten, dann nutzen Sie es nicht. KI darf helfen, aber nie Ihre einzige Wissensquelle sein. Und vor allem: Sie darf Ihnen nicht das Denken abnehmen, sonst verlernen Sie, selbst zu denken.

Wenn Sie nicht mehr verstehen, was passiert, haben Sie ein Problem. Der falsche Ansatz ist also zu sagen, dass es schon irgendwie passen wird. Der richtige ist, herauszufinden, was passiert und warum. Heute gilt dasselbe wie vor 30 Jahren: Tiefer Einstieg in die Materie ist anstrengend, aber lohnenswert. Er kostet Zeit, Disziplin und Ausdauer. Doch genau das unterscheidet Austauschbarkeit von Exzellenz. Wer sich dem KI-Trend einfach hingibt, wird untergehen. Echte Entwicklerinnen und Entwickler hingegen werden die neue Elite der IT-Welt sein.

Was bedeutet das nun für Sie? Ganz einfach: Verlassen Sie sich nicht auf KI. Wählen Sie nicht den bequemen Weg. Dieser führt in die Abhängigkeit. Wollen Sie langfristig gefragt sein? Dann denken Sie selbst. Die Frage, die Sie sich heute stellen müssen, lautet: Wollen Sie langfristig erfolgreich sein oder nur kurzfristig bequem?


(mai)



Source link

Weiterlesen

Entwicklung & Code

Testing Unleashed: Aktuelle Herausforderungen für Tester


In dieser Episode seines englischsprachigen Podcasts „Testing Unleashed“ spricht Richard Seidl über die Bedeutung von Qualität als Haltung im Software Testing. Er zeigt, wie sich die Rolle des Testers in den letzten Jahrzehnten gewandelt hat.

Richard Seidl betont die Notwendigkeit, Qualität als integralen Bestandteil des gesamten Softwareentwicklungsprozesses zu betrachten. In Zeiten von Agile und DevOps sind neue Denkansätze gefragt, um den Herausforderungen der Softwarequalität zu begegnen.

Dieser Podcast betrachtet alles, was auf Softwarequalität einzahlt: von Agilität, KI, Testautomatisierung bis hin zu Architektur- oder Code-Reviews und Prozessoptimierungen. Alles mit dem Ziel, bessere Software zu entwickeln und die Teams zu stärken. Frei nach dem Podcast-Motto: Better Teams. Better Software. Better World.

Richard Seidl spricht dabei mit internationalen Gästen über modernes Software-Engineering und wie Testing und Qualität im Alltag gelebt werden können.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Testing Unleashed: Aktuelle Herausforderungen für Tester“ und steht auf YouTube bereit.


(mdo)



Source link

Weiterlesen

Beliebt