Komputer to bardzo szybki, ale całkowicie dosłowny wykonawca

Komputer to deterministyczna maszyna stanowa #

Mózg komputera - procesor (CPU) - jest pozbawiony zdolności poznawczych w jakimkolwiek sensie tego słowa. Nie analizuje celu programu. Nie ma kontekstu. Nie zgaduje. Wykonuje dokładnie to, co zostało zakodowane w aktualnie wykonywanej instrukcji - po czym przechodzi do następnej.

Formalnie: CPU to maszyna stanowa, w której stan w chwili t+1 jest deterministyczną funkcją stanu w chwili t i pobranej instrukcji. Stan to zawartość rejestrów (kilka, kilkanaście słów maszynowych), pamięci RAM (gigabajty) i flag procesora (carry, zero, sign, overflow). Instrukcja to liczba zakodowana w opcode’ie, który ALU potrafi zinterpretować.

Cykl maszynowy: fetch-decode-execute #

Każdy cykl zegara CPU robi mniej więcej to samo:

1. Fetch - z rejestru IP (Instruction Pointer) odczytuje adres następnej instrukcji, ładuje ją z pamięci do rejestru instrukcji.
2. Decode - dekoder rozpoznaje opcode i operandy. „To jest ADD, dwa rejestry, wynik do trzeciego.”
3. Execute - ALU lub jednostka logiczna wykonuje operację. Wynik trafia do rejestru lub pamięci.
4. Increment - IP przesuwa się na następną instrukcję (chyba że to skok).

To są nanosekundy. Na 4 GHz CPU - cztery miliardy takich cykli na sekundę, na rdzeń. Współczesne procesory są jeszcze sprytniejsze (pipelining, out-of-order execution, branch prediction, speculative execution), ale fundamentalnie wykonują wciąż ten sam cykl.

Paradygmat imperatywny #

Większość kodu, który piszemy w C#, Javie, Pythonie - to programowanie imperatywne. Programista deklaruje krok po kroku, co i w jakiej kolejności ma się stać. To jest naturalne mapowanie na to, jak pracuje CPU.

Inne paradygmaty (funkcyjny, deklaratywny, logiczny) opisują co chcesz, a kompilator/runtime tłumaczy to na imperatywne kroki. Ale na samym dole - po wszystkich warstwach abstrakcji - i tak ląduje sekwencja prostych instrukcji dla CPU.

Naleśnikowy “przepis” w C# wygląda mniej więcej tak:

// title: NalesnikRecipe.cs
public class NalesnikRecipe
{
    public Nalesnik Make(Skladniki skladniki, Patelnia patelnia)
    {
        // 1. Alokacja zasobów - bufor pod ciasto
        var ciasto = new Ciasto(capacity: 500); // ml

        // 2. Mieszanie - pętla z warunkiem stopu
        while (ciasto.MaGrudki())
        {
            ciasto.Mieszaj();
        }

        // 3. Smażenie - dla każdej porcji
        var nalesniki = new List<Nalesnik>();
        while (ciasto.Objetosc > 0)
        {
            var porcja = ciasto.OdmierzPorcje(50); // ml
            patelnia.Wlej(porcja);

            // Czekaj aż się zarumieni - z warunkiem stopu (kluczowe!)
            while (!porcja.Zarumieniona && porcja.CzasNaPatelni < 90)
            {
                Thread.Sleep(100);
            }

            if (porcja.CzasNaPatelni >= 90)
                throw new SpalonyNalesnikException();

            patelnia.Przewroc(porcja);
            nalesniki.Add(patelnia.Zdejmij());
        }

        return nalesniki.Last();
    }
}

Wszystko, co tu widzisz, to fundamentalne konstrukcje:

• Alokacja pamięci: new Ciasto(...) - rezerwacja bloku w heap.
• Pętla z warunkiem: while (...) - bezpośrednio mapuje na compare + conditional jump na poziomie ASM.
• Instrukcja warunkowa: if (...) - tak samo, compare + jump.
• Wywołanie funkcji: patelnia.Przewroc(...) - push argumentów na stos, jump do adresu funkcji, return value w rejestrze.
• Wyjątek: kontrolowany skok do bloku catch w warstwie wyżej, plus rozwinięcie stosu.

Dlaczego to się nazywa „głupia maszyna” #

Bo CPU nie ma jak rozpoznać, że twój kod jest nielogiczny. Jeśli napiszesz:

// title: BadDivision.cs
int x = 10;
int y = 0;
int z = x / y;  // DivideByZeroException

CPU wykona instrukcję IDIV. Sprzętowo zgłosi wyjątek (#DE na x86), bo to jedna z niewielu rzeczy, na które ALU jest uczulone. Ale gdyby nie ten sprzętowy guard, CPU zwróciłby śmieciowe wartości i poleciał dalej. Wszystko jest „legalne”, dopóki dekoder rozumie opcode.

To jest też powód, dla którego buffer overflow są tak niebezpieczne. CPU nie wie, że pamięć poza tablicą „nie powinna być nadpisana”. Widzi tylko adres + rozkaz MOV. Robi, co mu kazano.

Infinite loop, stack overflow, OOM #

Trzy klasyczne sposoby, na które program się wywala, gdy programista się zagapi.

Infinite loop #

// title: InfiniteLoop.cs
while (true)
{
    naleSnik.Smaz();
    // Brak warunku zakończenia. Brak break.
}

CPU będzie wykonywał te instrukcje w nieskończoność. Jeden rdzeń ucieknie do 100% wykorzystania, wentylator zacznie wyć, a system operacyjny w pewnym momencie albo zabije proces (timeout watchdog), albo użytkownik kliknie End Task.

Z punktu widzenia CPU - nic złego się nie dzieje. Wykonuje legalne instrukcje, zegar tyka, wszystko działa. To system operacyjny i scheduler zauważają, że proces zachowuje się patologicznie.

Stack overflow #

// title: InfiniteRecursion.cs
void Smaz()
{
    Smaz();  // wywołuje samą siebie bez warunku stopu
}

Każde wywołanie funkcji rezerwuje stack frame - kawałek pamięci na stosie pod parametry, lokalne zmienne, adres powrotu. Stos w .NET ma domyślnie 1 MB na wątek. Kilka tysięcy wywołań i bum - StackOverflowException. CLR nawet nie próbuje tego łapać, bo nie ma już gdzie - zabija proces natychmiast.

Out of memory #

// title: MemoryLeak.cs
var lista = new List<byte[]>();
while (true)
{
    lista.Add(new byte[1024 * 1024]); // 1 MB rocznie
}

Heap (managed lub native) ma ograniczenie - na 64-bit Windows zwykle 8 TB wirtualnej, ale w praktyce kończy się na fizycznej + swap. Gdy alokator nie ma już co dać, rzuca OutOfMemoryException. Proces może to złapać i się ratować, ale zwykle leży.

We wszystkich trzech przypadkach CPU robił dokładnie to, co mu kazano. Bug nie jest w sprzęcie. Bug jest w przepisie.

Co AI w to wnosi #

LLM-y to wielowarstwowe sieci neuronowe wykonywane na GPU/TPU. Pod maską to dalej imperatywny kod - mnożenia macierzy, funkcje aktywacji, gradient descent przy treningu, propagacja w przód przy inference.

Różnica jest taka, że przepis jest wyuczony, nie ręcznie napisany. Zamiast programisty piszącego „jeśli A, to B”, masz 175 miliardów liczb (parametry modelu), które razem definiują funkcję tekst → następne słowo.

Ale procesor wciąż wykonuje cykl fetch-decode-execute. CPU/GPU nie „rozumie” co liczy. Mnoży macierze, bo dostał taką instrukcję. Magia jest gdzie indziej - w tym, że ten zestaw mnożeń jest na tyle dobrze dobrany, że po wielu warstwach wygląda jak rozumienie. To nie jest rozumienie. To jest niewyobrażalnie precyzyjna interpolacja statystyczna.

Pułapki dla początkujących #

• Zakładanie, że „komputer się domyśli”. Nie domyśli się. Pisz wszystko jawnie. Brak else znaczy „zrób nic”, a nie „zachowaj się rozsądnie”.
• Pominięty warunek stopu w pętli/rekurencji. Najczęstszy sposób na crash. Każde while, for, każda rekurencja musi mieć udowodniony case bazowy.
• Niezamknięte zasoby (pliki, sockety, połączenia z bazą). CPU ich nie zamknie sam - GC zwalnia pamięć, ale nie zwraca uchwytów. Stąd using, IDisposable, try/finally.
• Race condition na wątkach. Dwa rdzenie wykonują instrukcje równolegle - bez locka/atomicity gwarancji wynik bywa losowy. CPU nie wie, że dwie operacje „powinny być” niepodzielne.
• Mylenie warstw abstrakcji. „LINQ tego nie zrobi efektywnie” - LINQ pod spodem to imperatywne pętle wygenerowane przez kompilator. Każda abstrakcja kończy się na ASM-ie.

Skrótowo #

CPU to deterministyczna maszyna stanowa wykonująca cykl fetch-decode-execute. Programowanie imperatywne to bezpośrednie mapowanie na ten model: krok po kroku. Każdy bug to brakująca lub sprzeczna instrukcja, nie wada sprzętu. AI nie zmienia tej zasady - dodaje warstwę wyuczonego przepisu, ale pod spodem wciąż jest zwykły kod liczący macierze. „Komputer jest głupi” to nie żart - to architektoniczna prawda, która wszystko upraszcza.