Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Tiles hat geschrieben:
Ansonsten, gib mal im Startmenü Aufgabenplanung ein und schau was da so alles aktiv ist. Da stehen auch noch ein paar nette Sachen. Und uah, da stehn ja bei mir echt nen paar komische Dinger drin. WTF? Täglich Lenovo Customer Feedback Programm 64. Wann habe ich mir das denn eingefangen O_O
Woah, das Ding ist ja riesig. Ich weiß gar nicht, wie ich da zwanzig Jahre nicht drin rumspielen konnte.
Allerdings: Es ist auch ziemlich unübersichtlich, es gibt einfach eine Millionen Tasks mit merkwürdigen Namen bei denen ich nicht weiß, ob ich will das sie laufen, oder nicht. Gibt es irgendeine Möglichkeit zu sehen, welcher Task wie viel verbraucht? Ich habe irgendwie wenig Lust, von 100 Tasks zu googeln, was genau sie machen und dann zu entscheiden, ob ich sie will, oder nicht. Das meiste scheint im Taskmanager unter svchost zu laufen, was wohl nur ein generischer Starter ist und so ziemlich alles sein kann.
Aber wenigstens weiß ich jetzt, wie ich meinen Autoupdater automatisiert starten kann, wann immer eine Internetverbindung aufgebaut wird. Falls ich mal einen schreiben sollte...
Bei mir ist da übrigens gar nicht so viel drin. 37 Einträge. Ich würde mal grundsätzlich bei allem misstrauisch werden was nicht Microsoft ist. Und bei Microsoft bei allem was Experience im Namen trägt. Um Goolge wirst du da aber nicht rumkommen.
Ja, sowas hat der MS-Compiler auch. for löst grundsätzlich alle möglichen Optimierungen (von sinnig bis unsinnig) aus, do while bringt das, was man haben will.
Das ist ja noch garnix - wo wir schonmal beim Jammern sind - meine Frau hat ohne mein Wissen beim ausmisten
nach gerade mal 15 Jahren meinen Zerbst Band I und Band II in den Müll geworfen ! :'(
Sie meinte nur - ist bestimmt eh total veraltet, von wegen ...
Ich bin da eher von der Fraktion Deiner Frau :) Ausmisten FTW :D Beim letzten Umzug musste praktisch meine ganze Programmierbuchsammlung (inkl. Zerbies Klassikern :)) dran glauben...
Ich nutze das schon seit … zehn? Jahren, und es ist der einzige Image Hoster, dem ich vertraue. Und plötzlich kommen die GIFs total kaputt raus. Scheiße.
Ich hatte mich auf den neuen Optimizer in Visual C++ 2015 Update 3 gefreut, aber er ist ein Haufen Scheiße.
Ich habe das Gefühl, dass *vor* Inlining optimiert wird. Irgendwie wird nicht mehr zwischen äußeren Funktionen und einer geinlineten aufgerufenen Funktion optimiert.
auto hasSucceeded = no;
// Load “d3d11.dll” (not available on XP, Vista without platform upgrade, etc.) and find the factory for all D3D 11
// interfaces, “D3D11CreateDevice()”:
if(auto d3d11_dll = Windows::tryToLoadModule(UTF16("d3d11.dll"))) {
if(auto createDevice = tryToFindFunction<decltype(D3D11CreateDevice)>(*d3d11_dll, "D3D11CreateDevice")) {
hasSucceeded = callCreateDevice(result, *createDevice, minimumRequirement, supervisorOrNull);
} else {
report(supervisorOrNull, Error::noD3D11);
}
// Leave the D3D 11 DLL allocated, it does no any harm and speeds up re-use.
// Windows::release(*d3d11_dll);
} else {
report(supervisorOrNull, Error::noD3D11);
}
return hasSucceeded;
111 Befehle in 395 B. Wenn man ins Disassembly schaut:
… dann sieht man, dass VC drei returns mit quasi identischen Befehlen in diese Funktion kompiliert hat. Entfernen wir die (leider nur in diesem Fall) überflüssige bool hasSucceeded:
Das ist genau das Verhalten, das man nicht erwartet hätte: Ergebnis in einer Variable festhalten und einmal return schreiben produziert drei Pfade. Ergebnis an zwei verschiedenen Stellen explizit returnen produziert nur noch einen. Scheiße!
Nun sind das in diesem Beispiel 15 % Größe, die flöten gegangen sind. Normalerweise kann sogar ich über sowas hinwegsehen. Aber das Problem ist überall, in fast jeder Funktion, deren Disassembly ich ansehe.
Sie hatten auch geprahlt, dass Windows und verschiedene Microsoft-Produkte mit dem neuen Compiler ein Promille kleiner geworden wären:
Meine Tools sind mit dem neuen Optimizer 20 % (!!!) größer geworden. Das kann ich an der x86-Version sehen, die vorher nur ein paar Prozent kleiner war, und jetzt neben x64 verschwindend klein aussieht. (Der neue Optimizer ist ausschließlich x64.)
Scheiße scheiße scheiße. Der Optimizer ist jung, und niemand erwartet nach dem ersten Release Perfektion. Dann postet aber bitte nicht diese lächerlichen Windows-Größenvergleiche (da sind eh die DLL-Ressourcen und Manifests und Lokalisierungen der Platzfresser, und 438 KiB Ersparnis auf über 1 GiB Daten klingt sogar in meinen Ohren armselig) und macht ihn zum Opt-In!
…
int x = 8;
foo(1 << x); // warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
Nagut:
foo(uint32_t(1 << x)); // warning C6297: Arithmetic overflow: 32-bit value is shifted, then cast to 64-bit value. Results might not be an expected value.
wat
foo(size_t(uint32_t(1 << x))); // warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
Wo ist das implizit? Warum nervt der Compiler mich damit? Warum seid ihr alle gefeuert?
Ich bin in Visual Studio mit meinem Firmenkonto angemeldet
damit werde ich auch automatisch in Chrome angemeldet, sobald ich Microsoft.com besuche
in Chrome wollte ich mich dann mit meinem Privatkonto anmelden
was passiert?
ALLES SCHROTT
jetzt leiten beide Konten auf die selbe Identität, aber mit unterschiedlichen E-Mail-Adressen, und die Privatinformationen wurden für das Firmenkonto übernommen und ich kann nichts mehr ändern weil ich nur noch das Privatkonto angezeigt bekomme, auch wenn ich mich mit Firmen-Credentials einlogge
WHAT THE FUCKING FUCK
trotz unterschiedlicher Namen, unterschiedlicher E-Mail-Adressen, unterschiedlicher Domains … jetzt sind das alles die Privatinfos
FUCK FUCK FUCK FUCK FUCK
DAS WAR DER GRUND, WARUM ICH SEIT ZWEI JAHREN KEIN FEEDBACK MEHR ABGEGEBEN HABE, GANZ GENAU DIESE SCHEIßE HATTE ICH DAMALS AUCH SCHON
Also.. dass das mit der Größe in deinen Programmen schlechter geworden ist, könnte ich mir durchaus mit deiner händischen Optimierung erklären. Du hast wahrscheinlich (unter)bewusst angefangen Code für den Compiler zu designen anstatt sich einzig um die Programmlogik und das Datengesign zu kümmern. Da jetzt der Compiler anders ist, ist jede Stelle, die für den alten Compiler toll war, für den neuen vielleicht lästig.
Vielleicht muss man Codeoptimierung über verschiedene Compiler gegenchecken und vielleicht auch einen Schritt zurücktreten: das Laden von DX11 ist kein Ort, um Optimierungen zu beurteilen, oder? ;-) Ist es mit -Os [das MSVC-äquivalent] compiliert?
Und wozu muss man sich beim Programmieren neuerdings anmelden? :-O
Ja; du hast mit der Optimierung auf den Compiler wahrscheinlich recht. Allerdings:
Der alte Optimizer war stark lokal begrenzt, wegen den Wurzeln auf DOS mit 64 KiB RAM. Der Optimizer hat eigentlich äquivalente Code-Stücke unterschiedlich optimiert, wenn z.B. die Reihenfolge der Operationen unterschiedlich war. Das galt als Gag bei Clang und GCC, weil die auf Static Single Assignment Form aufbauen, und die ist dabei wesentlich robuster.
Der neue Optimizer von Microsoft baut ebenfalls auf SSA auf, deshalb sollte nun Schluss mit sowas sein. Was aber stattdessen passiert: semantisch äquivalente Code-Stücke werden wieder unterschiedlich optimiert, weil irgendwo eine temporäre Variable zu viel oder zu wenig ist. Aua.
Das Laden von D3D 11 war als Beispiel geeignet, weil es a) kürzer ist als die anderen Funktionen mit diesem Problem und b) ich gerade davor saß als mir der Kragen platzte. Optimiert war der Code in beiden Fällen für Geschwindigkeit.
Und wozu muss man sich beim Programmieren neuerdings anmelden? :-O
Man muss sich in Visual Studio mit einem Microsoft-Konto anmelden, um es kostenlos nutzen zu können. Um Bugs zu melden muss man sich erst mit seinem Microsoft-Konto anmelden, und dann ein damit verknüpftes Microsoft Connect-Konto erstellen, oder so ein ähnlicher Schwachsinn.
Optimiere mal auf Code-Größe und gucke, was passiert.
Die performancekritischen strücke kannst du, solange du mehere cpps hast , getrennt auf Geschwindigkeit optimieren.
Ich vermute fast, dass das mehr bringt als jede händische optimierung.
Du weißt, wo du keinen Platz verschwenden willst -> CPP auf Größe kompilieren. Du weißt, welcher Code kritisch ist -> auf Geschwindigkeit optimieren.
Hast du beide Optimierungsziele in einer CPP, sortiere um.
kA, was LTO dann macht.. aber einen Test ist es Wert.
Berichte :-)
Aber ich verstehe die Frustration. Optimizer sollten sich deterministisch verhalten. Aber GCC tut das auch nicht.
DerAlbi hat geschrieben:Optimiere mal auf Code-Größe und gucke, was passiert.
Aber das tut doch nichts zur Sache: Wenn es ein Ding der Optimierung auf Geschwindigkeit WÄRE, müssten ja trotzdem beide Versionen identisch sein, weil der Compiler äquivalenten Code gegen ein gemeinsames Optimum transformieren soll!
Die performancekritischen strücke kannst du, solange du mehere cpps hast , getrennt auf Geschwindigkeit optimieren.
Ich vermute fast, dass das mehr bringt als jede händische optimierung.
Du weißt, wo du keinen Platz verschwenden willst -> CPP auf Größe kompilieren. Du weißt, welcher Code kritisch ist -> auf Geschwindigkeit optimieren.
Hast du beide Optimierungsziele in einer CPP, sortiere um.
kA, was LTO dann macht.. aber einen Test ist es Wert.
Für sowas gibt es Profile-Guided Optimization ;) In Visual C++ wird dann auch eine Klasse neuer Optimierungen aktiv, die so nicht zur Verfügung stehen (z.B. Optimierung auf Sprungvorhersage).
Aber ich verstehe die Frustration. Optimizer sollten sich deterministisch verhalten. Aber GCC tut das auch nicht.
Ja; um mal cbloom zu zitieren:
We've struggled a lot with modern clang/LLVM/GCC. The problem is that you poke at the code in some seemingly innocuous way and the performance jumps massively because it either enables or disables some optimization opportunity. It makes iterative tweaking almost impossible, because it's hard to tell if some little change was actually a fundamental algorithm improvement, or if it just tripped the optimizer into something else.
Er hält dem VC++ gegenüber, das den Code wörtlicher nimmt. Aber das ist jetzt wohl vorbei.
Ich verstehe deinen Punkt schon und mich kotzt diese konzeptuelle schwäche auch an. Das ist letztlich vergleichbar mit den "äquivalenten" Schleifen, die ich bisschen über dir geschrieben hatte.
Ich weiß auch nicht, wieso das so ist. Das sieht nach einem konstruktionsfehler im Compiler aus.
Wenn das gleiche dasteht, muss auch das gleiche rauskommen.
Als würden die Optimizer-Passen in der falschen Reihenfolge und nur 1x geschehen oder so.
Lass uns einen ZFX-Compiler bauen. Danach verstehen wir, warum das alles nicht so geht, wie wir wollen.
Sagmal, diese behinderten Flash-Player Updates gibt es doch nur noch, damit man irgendwann einmal aus Versehen nicht die angebotene Zusatzsoftware abwählt, oder?
Ich stelle es mir äußerst schwierig vor, einen Video-Player zu schreiben, der so unstabil ist, dass alle zwei Wochen eine neue kritische Sicherheitslücke gefunden werden kann. Das Ding ist kein Betriebssystem, das Ding spielt Videos ab (oder nicht?). Natürlich ist das nicht unbedingt trivial, aber es ist doch trotzdem überschaubar. Und selbst wenn es so kaputt sein sollte, hätte man da nicht langsam mal auf die Idee kommen müssen, eine Neuentwicklung zu beginnen? Vielleicht in einer dieser coolen neuen Programmiersprachen, die von Haus aus 95% aller Fehler die man in z.B. C so machen kann komplett verhindern?
Natürlich würde ich den am liebsten gar nicht mehr installiert haben. Aber ab und zu landet man dann doch nochmal auf einer Webseite, wo dann die Videos nicht mehr funktionieren. Kaputtes Internet ist dann auch irgendwie doof.
Naja, Flash ist eben doch ein wenig mehr als nur ein Videoplayer. Das ist im Grunde eine kleine Spieleengine samt eigener Sprache. Siehe Flashgames. Die Neuentwicklung heisst WebGL. So richtig einzuschlagen scheint das aber auch nicht irgendwie :/
Sichere VMs zu entwickeln, die performanten Zugriff auf die Hardware haben, ist einfach nicht so leicht... Als Entwickler bin ich ein Fan von Flash und AIR. Das sind wirklich gute Werkzeuge, die vielen Leuten ein Auskommen mit "digitalen Kulturprodukten" beschert haben.
Flash … Adobe … Sicherheitsprobleme … da war doch was … ach ja, fefe!
Der aktuelle Höhepunkt in diesem Kasperletheater ist der Security-Chef von Adobe (Der Brüller! Adobe hat tatsächlich einen Security-Chef!)
Der hat sich tatsächlich hingestellt (auf einer Kaspersky-Konferenz, das passt auch mal wieder wie Arsch auf Eimer) und dem staunenden Publikum erklärt, dass es Adobe ja gar nicht darum geht, die Bugs zu fixen. Stattdessen sei das Ziel, das Ausnutzen der Bugs teurer zu machen. Und aus diesem Gesichtspunkt verurteilte er die Forscher, die es wagen, Papiere darüber zu veröffentlichen, wie man die sinnlosen Mitigations umgeht.
Weil ja immer viel zu wenig wirtschaftliches Denken in der Schule gelehrt wird, nochmal deutlich: Adobe als Firma ist nicht primär dazu da, deinen Computer mit sicherer Software zu bereichern, sondern ihren Gewinn zu maximieren. Bugs beheben kostet Zeit und damit Geld. Zu viele Bugs wiederum verhindern, dass sie mit ihrer Adware gewisse Kunden erreichen. In der Gewinnfunktion sucht man nun ein Maximum. Das liegt augenscheinlich dabei, bis ans Ende der Zeit jede Woche diezwei oder drei Sicherheitslücken zu stopfen, die gerade von besonders vielen Erpressungstrojanern ausgenutzt werden.
Neuentwicklungen sind wirtschaftlich eine besonders teure Katastrophe. Denn eine Neuentwicklung kostet nicht nur viel viel Geld, das sie erst Jahre später wieder einbringt, sondern sie hält das Entwickerteam auch davon ab, das bestehende Produkt zu erweitern, reduziert also zusätzlich dein bestehndes Einkommen. Ganz ab davon, dass sie nicht automatisch besser wird, weil man Rust benutzt, denn VM-Entwicklung ist – wie Chromanoid schon sagte – nicht trivial, und der ganze Code aus den Jahren davor existiert nicht zum Spaß.
