Beste Antwort
F: Warum verwechseln Programmierer immer Halloween und Weihnachten?
A: Weil der 31. Oktober == 25. Dezember!
Zwei Bytes treffen sich. Das erste Byte fragt: „Bist du krank?“. Das zweite Byte antwortet: „Nein, ich fühle mich nur ein bisschen unwohl.“
F: Wie viele Programmierer braucht man, um eine Glühbirne zu wechseln?
A: Keine, das „sa Hardwareproblem
F: Wie viele Microsoft-Programmierer benötigen Sie, um eine Glühbirne auszutauschen?
A: Keine, sie machen nur Dunkelheit zum Standard und sagen allen, „dieses Verhalten ist beabsichtigt „
Ein Informatikstudent studiert unter einem Baum und ein anderer hält an einem auffälligen neuen Fahrrad. Der erste Student fragt:“ Woher hast du das? „. Der Student auf dem Fahrrad antwortet:“ Während ich draußen studierte, hielt ein hübsches Mädchen an ihrem Fahrrad an. Sie zog sich aus und sagte: „Du kannst alles haben, was du willst.“ Die erste Schülerin antwortet: „Gute Wahl! Ihre Kleidung hätte wahrscheinlich nicht zu Ihnen gepasst.“
Ein Physiker, ein Ingenieur und ein Programmierer saßen in einem Auto und fuhren über einen steilen Alpenpass, als die Bremsen versagten. Das Auto wurde immer schneller, sie hatten Mühe, um die Ecken zu kommen, und ein- oder zweimal rettete sie nur die schwache Leitplanke vor dem Absturz am Berghang. Sie waren sich sicher, dass sie alle sterben würden, als sie plötzlich entdeckten eine Fluchtspur. Sie bogen in die Fluchtspur ein und kamen sicher zum Stillstand. Der Physiker sagte: „Wir müssen die Reibung in den Bremsbelägen und den daraus resultierenden Temperaturanstieg modellieren, um herauszufinden, warum sie versagt haben.“ Der Ingenieur sagte: „Ich glaube, ich habe ein paar Schraubenschlüssel hinten. Ich werde einen Blick darauf werfen und sehen, ob ich herausfinden kann, was“ falsch „ist. Der Programmierer sagte: „Warum machen wir uns nicht wieder auf den Weg und prüfen, ob es reproduzierbar ist?“
F: „Was ist der objektorientierte Weg, um reich zu werden?“
A. : Vererbung
Ein Programmierer an seine Freunde (auch Programmierer): „Ich habe letzte Nacht ein heißes Mädchen getroffen. Ich habe sie nach Hause gebracht und wir haben angefangen, uns wütend zu küssen. Ich habe sie auf die Tastatur gesetzt und …“. Alle Freunde sagten gemeinsam: „Sie haben einen Computer zu Hause? Was ist der RAM davon?
Eine SQL-Abfrage geht in eine Leiste, geht zu zwei Tabellen und fragt: „Kann ich mich Ihnen anschließen?“
Wenn Ihr Hammer ist C ++, alles sieht aus wie ein Daumen.
F: Wie viele Prolog-Programmierer sind erforderlich, um eine Glühbirne zu wechseln?
A: Ja.
A. Der Programmierer stellt vor dem Schlafengehen zwei Gläser auf seinen Nachttisch. Ein voller, falls er durstig wird, und ein leerer, falls er es nicht tut.
Ein Mann steht an der Straßenecke und raucht eine Zigarette nach der anderen. Eine Dame geht an Notizen vorbei er und sagt „Hey, weißt du nicht, dass diese Dinge dich töten können? Ich meine, hast du nicht die riesige Warnung auf der Schachtel gesehen?!“ „Das ist in Ordnung“, sagt der Typ und pustet beiläufig „Ich“ ma Computerprogrammierer „.“ Also? Was hat das mit irgendetwas zu tun? fragte die Dame. Er antwortete: „Wir kümmern uns nicht um Warnungen. Wir kümmern uns nur um Fehler. „
Es gibt 10 Arten von Menschen auf der Welt. Diejenigen, die Binärdateien verstehen und diejenigen, die regelmäßigen Sex haben.
Also geht dieser Programmierer auf ein Date mit einem heißen Küken
Antwort
Sie sind sehr schlecht.
Sie sind die Leute, die ein fein abgestimmtes System mit einer „offensichtlichen“ Lösung modifizieren und alles schrecklich vermasseln, mit den absolut besten Absichten.
Um Ihnen eine Idee zu geben, ein weiterer hervorragender Ingenieur, den ich kenne Jeffrey Hsu arbeitete bei ClickArray (jetzt bekannt als Array Networks) und ließ mich dort einstellen, weil er einen anderen „Big Gun“ -Typ brauchte, um wirklich leistungskritische Arbeit zu leisten.
Und wir haben es geschafft
Auf 1,3-GHz-Pentium 4-Systemen (es war 2001).
Wir haben einen Reverse-Proxy-Cache mit bis zu 38.700 TCP-Verbindungen pro Sekunde – was nicht beeindruckend ist , bis Sie feststellen, dass es nur 16.384 verwendbare Ports für INADDR\_ANY gibt, es sei denn, Sie ändern im Wesentlichen Für den TCP / IP-Stack, wenn es sich um ein BSD- oder Linux-basiertes System handelt.
Wir hatten den Stack nicht geändert – es war ein BSD-Stack -, was bedeutete, dass wir auch auf anfängliche Seitenladeanforderungen reagierten gleicher Zeitrahmen.
Und dann waren wir beim nächsten Problem
Ungefähr einen halben Monat nach dem nächsten Problem, anscheinend jemand hatte endlich einige Zeit gebraucht, um einige Leistungstests für die Änderungen durchzuführen, die sie am Rest des Codes im Cache vorgenommen hatten.
Wir sahen eine zunehmende Panik im Büro für eine ein paar Tage und fragte mehrmals, was das Problem sei, und wurde angewiesen, sich keine Sorgen zu machen und weiter an dem zu arbeiten, woran wir arbeiteten.
Wir haben es getan, weil wir die Finite-State-Maschine repariert haben eine tatsächliche endliche Zustandsmaschine zu sein und den Cache-Code zu der Zeit umzustrukturieren. Dies ist eines der Dinge, die dem Unternehmen tatsächlich die nächste Finanzierungsrunde beschert haben.
Schließlich haben uns ihre Hotshots angerufen, um zu sehen, ob wir ihr Problem beheben können.
Sie erhielten ungefähr 6.300 Verbindungen pro Sekunde.
Sie hatten etwa das 6-fache an Leistung verloren und konnten nicht herausfinden, wo.
Es hat ein paar Stunden gedauert, und wir haben es schließlich auf ein Commit „Optimierung für mehrere CPU-Maschinen vornehmen“ zurückgeführt.
Wir haben es rückgängig gemacht und waren wieder auf ungefähr 35.000 Verbindungen pro Sekunde zurückgekehrt ein paar heiße Codepfade, und am Ende des Tages waren wir wieder auf den alten Zahlen.
Um die „Optimierung“ zu verstehen, die die “ Hot-Shot-Programmierer “, dachte er, man muss verstehen, dass das Einfädeln zu dieser Zeit nicht wirklich wichtig war.
Selbst wenn es so gewesen wäre, arbeiteten wir immer noch an der Zustandsmaschine Dies musste durchgeführt werden, bevor der globale Status möglicherweise in ein einzelnes „statite“ -Objekt verschoben werden konnte, um es pro Thread zu erstellen und zu verhindern, dass sich Instanzen gegenseitig stören.
Das Skalierungsmodell sollte also haben mehrere „Arbeit zu erledigen“ Motoren als p Prozesse und dann ein „Gatekeeper“ -Prozess, bei dem ein Prozess eine eingehende Anfrage bearbeiten kann. Er sah alle Anfragen und „ließ den Prozess los“. Wenn es mehr Anfragen gäbe, würde die Warteschlange im Gatekeeper „einen anderen Prozess loslassen“ und so weiter.
Unser „heißer Schuss“ hatte bemerkt, dass ein Prozess fast die gesamte Anfrage bearbeitet, während der andere Prozesse waren (meistens) inaktiv.
Dies liegt daran, dass ich absichtlich ein LIFO anstelle eines FIFO für die Prozesse verwendet hatte, die auf „Arbeit zu erledigen“ warteten.
Also „reparierte er „Es durch Ändern in ein FIFO.
Und die Leistung ging zur Hölle.
Der Grund, warum ich ein LIFO verwendet hatte Der erste Ort, obwohl ich wusste, dass es nicht unbedingt die Last zwischen den Kernen aufteilen würde, war, weil ich einige Dinge wusste, die der „heiße Schuss“ nicht wusste.
Ich wusste, dass:
- Als Netzwerk-Appliance waren wir fast immer an E / A und nicht an die CPU gebunden, es sei denn, wir luden in ein Modul, um beispielsweise Leerzeichen zu entfernen oder Inhalte für Werbezwecke neu zu schreiben
- Genauer gesagt, ich wusste, dass der letzte Prozess, der in Einklang gebracht wurde, begann g alle Seiten im Kern zu haben, während diejenige, die am längsten im Leerlauf gesessen hat, wahrscheinlich nicht alle Seiten im Kern haben würde.
- Außerdem ist es neu, dass es seitdem TLB-Cache-Kollisionen geben würde Alle Space-Prozesse des Benutzers wurden im selben Adressbereich zugeordnet, was zu Flushes führte.
- Dies bedeutete, dass Cache-Neuladungen erforderlich waren, was minimal bedeutete, dass mindestens L1 und wahrscheinlich L2-Cache
- In Kombination würde dies zu zusätzlichen Verzögerungen bei der Anweisungspipeline führen, da in der P4-Architektur kein L3-Cache vorhanden war.
- Und so habe ich absichtlich gehandelt, was ich wusste, dass es sich wahrscheinlich um inaktive CPU-Zyklen auf der zusätzlichen handelt Kerne für das, was ich wusste, würden die beste E / A-gebundene Leistung haben.
ausgegeben wurden
Also hatte ich absichtlich eine LIFO-Bestellung ausgewählt und eine Leistungsverbesserung mithilfe einer Technik überprüft, die ich 1994 zum ersten Mal verwendet hatte oder so genannt (von mir, seit ich die Technik erfunden hatte) „Hot Engine Scheduling“.
Also hatte dieser „Hot Shot“ den Pe zerstört Leistung aufgrund der Änderung.
Und dann konnte nach der angeblichen „Optimierung“ kein Leistungstest durchgeführt werden, um zu überprüfen, ob es sich tatsächlich um eine Optimierung handelte.
Das einzige, was er d prüfte, ob unter Last alle Prozesse im Laufe der Zeit ungefähr die gleiche CPU-Auslastung aufwiesen, was er jedoch damit meinte, dass er eine bessere Multicore-Auslastung erzielen würde.
Die absolut schlechtesten Softwareentwickler sind diejenigen, die gut genug sind, um gefährlich zu sein, aber nicht gut genug, um zu erkennen, wenn sie eine schlechte Entscheidung treffen.
Sie werden noch schlimmer, indem sie nicht überprüfen, ob die Entscheidung tatsächlich schlecht war, indem sie die Ergebnisse ihrer Änderungen mit einem unparteiischen Lineal messen.