Beiträge von niwax

    Es kann sein, dass die .net-Runtime automatisch der 300 folgt und dort dann kein Dokument findet. Oder umgekehrt, der Proxy überprüft nicht wirklich, was der Server gesagt hat und einfach nichts findet. Das Debuggen war größtenteils Glück und schwarze Magie, es kann also einfach irgendeine Eigenart in irgendeiner Software sein (höchstwahrscheinlich im Proxy...). Die Chancen das schnell zu beheben sind recht niedrig.

    Kanns gleich nochmal wo hochladen wenn ich das Projekt finde. Hatte leider zwischendrin mal nen Festplattencrash, sollte aber noch wo rumliegen



    Das ist die aktuellste Version die ich noch habe. nHTTP2.zip ist ein neuerer Debug-Build, der soweit ich mich erinnere auch mit gzip-komprimierten Websites umgehen kann und automatisch entpackt


    Hey click! ich hätte auch noch Interesse an deiner ISO ;)
    Nebenbei, Windows Embedded Posready 2009 ist ja ein XP SP3 mit ein paar Embedded Funktionen. Das kriegt noch Updates bis 2019 (http://Extended support until April 2019).
    Ev lassen sich diese dann auch auf einem normalen XP Sp3 installieren.
    Oder ein paar Updates der Firmen mit erweiteren Supportverträgen landem im Netz ;)

    Die übliche Kasse hängt aber nicht ungeschützt am Internet. Ich würde nicht drauf setzen, dass der Support das System gegen die Attacken absichert, die für dich die größte Gefahr sind, sondern es geht eher darum, alte Programme zu unterstützen und das System zB in ein Unternehmensnetzwerk einzubinden

    die Schleifenvariable muss ja auch im entrollten Zustand zwischen den einzelnen Schritten noch iteriert werden


    Nein, da das Unrolling meistens nur geht, wenn die Grenzen der Schleife schon bekannt sind, können einfach die entsprechenden Zahlen eingesetzt werden. In diesem Beispiel können zB sogar auch Speicherzugriffe in der Tabelle vereinfacht werden.

    Spoiler anzeigen


    Dabei spart man sich zwei Dereferenzierungen pro Zugriff und der Compiler kann sogar im voraus kleinere Puffer aus den Konstanten vorberechnen. Am Ende liegen auch nur 192 Multiplikationen im Cache.

    Wie viel Platz belegt wird, hängt auch von der Anzahl der Schleifendurchläufe ab.


    Natürlich, aber durch die kleine Größe wird der Cache dadurch bei weitem nicht voll. 64x256 Bit sind immer noch erst 2 KByte. Damit das dem Cache gefährlich wird, musst du schon auf ner sehr alten Architektur arbeiten.


    etwas OT: lohnt sich Loop Unrolling denn überhaupt in nennenswertem Umfang? also für zwei iterationen leuchtet mir das ja noch ein, aber den gesamten schleifenrumpf irgendwie 8x oder so zu replizieren bläßt den code doch ungemein auf und verschlechtert damit die cache-lokalität deutlich. bei moderenen sprungvorhersagen ist es doch bestimmt einfacher die schleife schleife sein zu lassen, sodass sie komplett im Cache abläuft und anderen Krams nicht verdrängt

    Gerade bei kleinen Loops bringt das extrem viel. Wenn du zB Videos oder Bilder dekodierst, sind die üblicherweise in Makroblocks unterteilt, was bedeutet dass du zwei verschachtelte Loops hast, die letztendlich in jeder Runder nur eine Handvoll Instruktionen ausführen. Ohne Unrolling hättest du enormen Overhead weil nach jeder Ausführung von zwei oder drei Instruktionen zuerst noch eine Manipulation an der Schleifenvariablen kommt dann ein GOTO, das dazu auch noch konditional ist. Im schlimmsten Fall schlägt also bei Blocks von 8x8 Pixeln die Branching Prediction des Prozessors mindestens alle acht Runden ins leere und die gesamte Pipeline muss ausgeräumt und neu aufgebaut werden. Von dem verbrauchten Cache ergibt sich kaum ein Unterschied, da Code bei dem sich das Unrolling lohnt meistens nur ein paar Instruktionen hat. Dazu kommt, dass der Overhead entfällt und bei diesem Beispiel je vier (oder noch mehr mit AVX/AVX2) Durchläufe in eine Instruktion gepackt werden können.


    Aaaach, 15k USD für ein iPhone mit Spiel vorinstalliert. Da merkt man, wo eigentlich der Dollar steht! :D

    Erinnert spontan an die eine Folge von Top Gear: "Wir haben nach 20 Meilen jetzt für fünf Pund getankt, für unsere ausländischen Zuschauer: Das sind etwa 5000 Kilometer und 20 Cent"


    Mein HTPC mit Windows 8.1 startet auch sehr flott. Hat auch eine normale HDD (5200 RPM) drinnen. Für den schnellen Startvorgang wird wahrscheinlich "Fast Boot" verantwortlich sein welches ja ein UEFI voraussetzt.

    Das schnelle Starten gibts auch mit BIOS schon, hab an nem uralten Laptop ne Bootzeit von etwa fünf Sekunden. Mit UEFI wird gar kein richtiger Bootloader mehr geladen, sondern auf das Herstellerlogo bzw was auch immer das EFI anzeigt folgt direkt die Anmeldeseite. Also quasi keine Startzeit oder eine Sekunde nach Knopfdruck