Hallo, der typischer Konsumer-PC mit Windows 7, Ubuntu 12.04 oder irgend so einem MacOS oder wie das heißt scheint ja doch so lange es ihn gibt eher als träge zu gelten. Man klickt etwas und es passiert mehrere Sekunden lang nichts. Und wenn dann doch was losgeht, ruckelt erst mal der Mauszeiger. Bei der aktuellen Rechenleistung sollte es doch gar keine Probleme mehr im Alltagsbetrieb geben. Selbst vor 20 Jahren gab es schon Computer mit aufwendigen grafischen Oberflächen und umfangreichen Anwendungen, die subjektiv verzögerungsfrei funktionierten. Es scheint ja irgendwas falsch zu laufen. Wie gut wird denn eigentlich ein aktueller PC ausgereizt? Werden die 64 Bit bei einem 64-Bit-System eigentlich wirklich genutzt, werden diese zusätzlich 16 (?) bei diesem System genutzt? Werden die ganzen Befehlssatzerweiterungen sinnvoll genutzt? Werden Bussystem effizient ausgelastet? Arbeitet die Speicherverwaltung + Cache sinnvoll? Werden eigentlich schon die ganze Abhängigkeiten und gegenseitigen Ausschlüsse sinnvoll verwaltet? Oder verbringt das System 90 % der Zeit mit Taskwechsel?
Er wird halt nicht ausgereizt. Alle OS sind überladen und so richtig schön bunt. Man verkauft halt einen PC oder ein OS wie eine Fertigpizza (außen schöm bunt und eine nackte Braut drauf - dann ist der Inhalt egal). Ein anderes Problem ist, die Kisten sind Universalgeräte, wie Software auch: Eierlegende Wollmilchsau halt. Kann alles und nichts richtig. Egal, der BWLer glaubt's und kauft's :-)
1. nicht jede Software ist auch wirklich gut programmiert. Es gibt genügend Programme (z.B. so manche PC Games), die einfach so schlecht programmiert sind, dass sie einfach langsam laufen. 2. die Ansprüche steigen immer weiter. Z.B. lief unter DOS lediglich ein Programm aktiv, der Rest wurde irgendwo im Speicher abgelegt und fertig. Allein der Ressourcen-Anspruch für Internet ist sehr sehr hoch. Beispiele: Flash, mehrere Websites parallel, HTML 5 mit mittlerweile 3D Javascript Grafiksachen. 3. Optimierung: früher wurde mehr Software wirklich in C hard gecoded. Heute nimmt man vermehrt auch interpretierte Sprachen, da sie einfach flexibler sind (z.B. beim Debuggen oder um systemübergreifend sein zu können). Beispiele wieder Internet mit Java, Javascript, C#, Lua usw. Diese (teilweise) interpretierten Sprachen sind oft um Faktor 10 bis 50 langsamer als C. Dafür laufen sie oft problemlos auf verschiedenen Betriebssystemen. 4. bei deiner Frage zu 64 Bit merke ich, dass du wahrscheinlich nicht so tief in der Materie drin steckst. 64 Bit kann man nutzen, allerdings bringen sie nicht immer überall etwas. Als allererstes kann man damit mehr Speicher allokieren. Bringt nur bedingt was... Wenn nur 2 GB drin stecken, sind 64 Bit für die Tonne. Bei Berechnungen ist es schon sinnvoller mit 64 Bit. Allerdings sind viele Ints trotzdem nur 32 Bit lang. Da hat man erst einen Vorteil, wenn man zufällig mehrere Zahlen mit gleicher Operation zusammen durchrechnen lassen kann (ich denke mal, sowas gibt es). Und ja, für Berechnungen bringen 64 Bit schon etwas. 5. Parallelisierung: Schau dir Amdahl's Law an. Unendliche Parallelisierung bringt nichts. Die zu bewältigenden Aufgaben müssen so geartet sein, dass sie auch parallelisiert werden können. Das geht beispielsweise bei iterativen Sachen sehr schwer. Außerdem ist es Unfug, bei der Kompression eines Jpegs 16 Cores zu verwenden, wenn 2 völlig ausreichen. In der letzten Zeit sieht man oft, dass einfach nur mehr Programme auf einzelne Cores gepinnt werden aber jedes Programm nur effektiv so schnell läuft, wie der Prozessortakt hergibt. 6. Es läuft auch immer mehr Müll im Hintergrund in Betriebssystemen mit. Z.B. Virenscanner, diverse Systemdienste usw. Auch grafische Oberflächen oder Annehmlichkeiten, wie das automatische Erkennen eines USB-Sticks kosten Ressourchen. 7. Und ja, mit passender Software können alle Ressourcen heutiger Rechner mit aktuellen Betriebssystemen fast vollständig ausgeschöpft werden. Das Problem ist nur: man muss erstmal solche Software haben. Und die genau hast du nicht im Alltag... 8. Hardware-Befehlssätze: Man kann damit auch nicht immer zaubern. Eine Addition wird nicht schneller, auch nicht durch lustige besondere ASM-Befehle. Natürlich gibt es Software, die auf solche Befehlssätze zurückgreift und damit auch einen großen Geschwindigkeitsschub bekommt. Aber nicht jede Software kann davon profitieren. Kein Mensch wird ein paar Berechnungen für Paint auf die Grafikkarte auslagern, weil es dort schneller geht. Der Aufwand ist einfach viel zu hoch und der Nutzen viel zu gering. Selbst in der heutigen Zeit nutzen viele ausschließlich SSE2, da die Befehle übersichtlich sind und das Wissen darüber weit verbreitet. Klar kann man AVX verwenden, aber wie viele PCs haben das schon? Daher nimmt man dann doch eher Sachen, die weit verbreitet sind um die Akzeptanz hoch zu halten. 9. Das Wissen zur Entwicklung guter Software ist nicht immer überall so gut verbreitet. Und ganz ehrlich: wenn man weiß, dass genügend Ressourcen vorhanden sind, wird auch nicht so sparsam entwickelt und so weit optimiert. Sonst würde heutzutage auch noch jeder C statt Java verwenden. 10. Ich glaube, dieser Thread ist nur entstanden aufgrund von Frust gegenüber einem Rechner. Räum einfach mal deinen Saustall in deinem Windoofs auf oder installier ihn neu oder suche nach den Bottlenecks des Systems. 11. eigentlich war die Response unsinnig...
Wenn Du an Deiner Kiste nichts macht verbringt die über 99% Rechenzeit im Leerlauf... Natürlich kann man so eine Kiste auch voll auslasten, das kommt dann vor allem den Projekten des distributed computing zugute... Dir eher nicht, Du darfst dann nur den Strom für die zahlen. Was die nämlich alle verschweigen ist, daß ein voll ausgelasteter PC deutlich mehr Strom verbraucht als einer im Leerlauf. Merkt man vor allem an der Grafikkarte - im Leerlauf dank Riesenkühler unhörbar, verlangt man ihr ein paar bunte Bilder aus dem neusten 3D-Egoshooter ab, startet im PC eine 747... Was die Betriebssysteme angeht: Wieso soll ich nicht nutzen was da ist? Programmiertechnisch kümmert sich der Compiler um die Verwendung der 64-Bit-Fähigkeiten. Es ist nicht immer ein Vorteil sowas zu nutzen... Die Addition zweier kleiner Zahlen (zB. 3+3) braucht keine 64 Bit zu nutzen. Es kann sogar schneller sein, sowas als 32-Bit-Operation in zwei Schritten auszuführen, anstatt erst eine 64-Bit-Operation vorzubereiten...
Rechner werden nicht schneller, jedenfalls nicht subjektiv. Die Reaktionszeit von Programmen bleibt in grober Näherung konstant. Statt dessen steigt die Komplexität von Programmen und Betriebssystemen jeweils so an, dass auf zeitgemässen Rechnern die akzeptable Reaktionszeit ungefähr erreicht wird.
Brater schrieb: > beispielsweise bei iterativen Sachen sehr schwer. Außerdem ist es Unfug, > bei der Kompression eines Jpegs 16 Cores zu verwenden, wenn 2 völlig > ausreichen. Schlechtes Beispiel, da justament Bild- und Videobearbeitung zu den am besten parallelisierbaren Aufgaben zählt. > In der letzten Zeit sieht man oft, dass einfach nur mehr > Programme auf einzelne Cores gepinnt werden aber jedes Programm nur > effektiv so schnell läuft, wie der Prozessortakt hergibt. Yep. Wie bei Ruder-Achter, nur andersrum. Einer rudert und 7 gucken zu. Immerhin gibts so schöne Dinge wie den Turbo-Modus, um wenigstens das thermische Budget auslasten zu können.
Ben _ schrieb: > Wenn Du an Deiner Kiste nichts macht verbringt die über 99% Rechenzeit > im Leerlauf... Fairerweise muss man sagen, dass sich gerade dieser wichtigste Modus des PC-Betriebs heute wesentlich effizienter gestaltet als früher. War es früher normal, dass ein Office-PC tagaus tagein um die 50W in Raumheizung umsetzte, sind es heute oft nur noch um die 25W.
Die SW, mit der ich hauptsächlich arbeite, reagiert spontan (auf mehrere Jahren alten PCs). Das ist Linux mit icewm als Windowmanager, EMACS, kein Eclipse, kein Developer Studio, keine Java-Programme, kein .NET... In der GUI gibt es keine merklichen Reaktionszeiten (außer halt, wenn ich nennenswert kompiliere, mit find und grep nach Dateien suche etc.). Ich weiß das sehr wohl zu würdigen; die zähe Reaktion hat mich bis vor ein paar Jahre lange genervt. Wenn man das heute noch hat, liegt es der SW - und an der sind die meisten Leute selbst schuld. Wie sehr die HW in den letzten Jahrzehnten zugelegt hat, merkt man, wenn man über diese Zeit weitgehend unveränderte SW nimmt. Der EMACS war vor 30 Jahren als langsam verschrien. Heute ist er ziemlich flink, während man mit einer aktuellen IDE arbeitet wie mit einer ständigen kleinen Bremse.
Stefan Helmert schrieb: > Wie gut wird denn eigentlich ein aktueller PC ausgereizt? Werden die 64 > Bit bei einem 64-Bit-System eigentlich wirklich genutzt, werden diese > zusätzlich 16 (?) bei diesem System genutzt? Werden die ganzen > Befehlssatzerweiterungen sinnvoll genutzt? Werden Bussystem effizient > ausgelastet? Arbeitet die Speicherverwaltung + Cache sinnvoll? Der wichtigste Schritt bei den 64 Bits ist die erweiterte Adressierbarkeit. Und da hätte beispielsweise ein Schritt auf 48 Bits locker ausgereicht, denn breiter adressieren die Prozessoren heute sowieso nicht (circa), nicht virtuell und schon garnicht physikalisch. Nur sind solche Wortbreiten etwas aus der Mode gekommen. Die meisten auf PCs laufenden Programme profitieren freilich weder davon, noch von der doppelten Breite der Integer-Verarbeitung. Aber ein paar eben schon, und deshalb gibt es das. Tatsächlich profitieren Programme am ehesten von einem Nebeneffekt der 64-Bit Verarbeitung: Es stehen aufgrund der Renovierung des Befehlssatzes im 64-Bit Modus doppelt so viele Register zur Verfügung, und das macht den Code effizienter. Ein wesentlicher Schritt zur Steigerung der Effizienz ist daher eine unlängst definierte Betriebsart in Linux, die 32-Bit Programme unter Nutzung des effizienteren 64-Bit Modus ermöglich, also mit 32-Bit Pointern aber allen Registern. Grad die 64-Bit Pointer sind nämlich in den weitaus meisten Programmen pure Bitverschwendung. AMD hatte den Befehlssatz immerhin pfiffig genug definiert, um das problemlos zu ermöglichen. > Werden eigentlich schon die ganze Abhängigkeiten und gegenseitigen > Ausschlüsse sinnvoll verwaltet? Oder verbringt das System 90 % der Zeit > mit Taskwechsel? Lässt sich nicht verallgemeinern. Zumal die Ansprüche an den Programmierer bei der Parallelisierung stark ansteigen. Es gibt Fallstricke, die dazu führen können, dass die Kommunikation der Threads untereinander die Performance drastisch reduziert, wenn Zugriff auf gemeinsame Resourcen zu häufig und in falscher Weise stattfindet (z.B. cache thrashing). Manchmal auch schon allein deshalb, weil es formal getrennte aber faktisch gemeinsame Resourcen sind (gleiche cache line). Kenne ich aus erster Hand, weil ein mir persönlich bekannter Programmierer justament über solche Effekte stolperte. Der normale Programmierer hat vom realen Ablauf bei Multiprocessing und den zugrunde liegenden Mechanismen der Hardware, wie Caching und dessen Konsistenzverfahren, wenig bis keine Ahnung. Müsste er aber haben, um solche Fallen zu vermeiden. An dieser Stelle passiert auch noch was. Intel ist grad dabei, Konzepte zur Effizienzsteigerung in die Prozessoren einzubauen (transactional memory). Nicht dass der Job dadurch viel einfacher würde - im Gegenteil - aber man kann so manche durch Thread-Kommunikation entstehende Performance-Fallen besser vermeiden.
Die SIMD Befehlssatzerweiterungen (MMX, 3dnow, SSE, SSE2, AVX, ...) werden in den meisten Programmen nicht genutzt. Weil die meisten Programme davon nicht profitieren. Für Mail, Excel, Word, SAP usw sind sie völlig nutzlos. Bei der Entwicklung solcher Befehlssätze war auch nicht immer die Effizienzsteigerung im Blick, sondern die Umsatzsteigerung. Die von Intel. Frühe Soundkarten führten recht viel Verarbeitung selbst durch, mit vergleichsweise recht hoher Effizienz, weil dafür optimiert und folglich wenig Energieverbrauch. Davon hatte Intel aber nichts, das Geld steckten andere ein. Also definierte Intel MMX, um diese Verarbeitung aus dem Audiochip in den Prozessor zu holen. Und da ist sie heute nun. Der real noch existierende Audio-Chip ist wenig mehr als ein A/D und D/A Wandler, den Rest macht die CPU. Nur dass diese CPU dafür ein paar Grössenordnungen mehr Strom benötigt, als ein dafür optimierter Audiochip bräuchte. Das ist zwar flexibler, aber eigentlich ausgesprochen ineffizient.
Klaus Wachtler schrieb: > Der EMACS war vor 30 Jahren als langsam verschrien. Heute ist er > ziemlich flink, EMACS = Eight Megabytes And Constantly Swapping. Der Emacs braucht heute nicht viel mehr Speicher, als zu der Zeit in der die besseren Unix-Möbel 8MB Speicher hatten. Aber heute sind 8MB ein Witz, da ist schon mancher CPU-Cache grösser. Aber an sowas erkennt man die Oldtimer. Bring das mal der nachwachsenden Generation bei. > während man mit einer aktuellen IDE arbeitet > wie mit einer ständigen kleinen Bremse. Aber dafür fehlen dir all die schönen 3D-Effekte, wie sich halbtransparent überlagernde Fenster! ;-)
Mist! Warum musstest du das sagen? Jetzt werde ich immer daran denken, und merken, daß es mir fehlt!
Um solchen die Performance steigernden und/oder die Kosten senkenden Effekte in Form alter Software auf neuer Hardware entgegenzuwirken hat man mittlerweile vorsorglich einen Riegel vorgeschoben. Versuch mal, ein noch vergleichsweise verbreitetes System wie den Windows Server 2003 direkt auf aktuellem Blech zu installieren. Nada, nichts geht mehr, keine Chance.
Es gibt da 2 Bewegungen, zum einen werden PCs wirklich immer effizienter. Die schaffen immer mehr pro Taktzyklus, und Betriebssystemskernel sind heute deutlich besser als früher. In den 1990gern war es beispielsweise nicht üblich, dass der Prozessor was machen konnte während er auf die Festplatte wartet. Das heutige Problem ist eher die Codegröße, da die Prozessoren um ein Vielfaches schneller sind als der Arbeitsspeicher. Ein Cache-Miss kostet hunderte von CPU-Zyklen. Je mehr vom Code in den Cache passt, um so schneller wird es. Auch sind die Fließkommaeinheiten heute viel schneller als noch in den 1990gern. Man hat quasi keinen Geschwindigkeitsnachteil wenn man mit Fließkommazahlen rechnet. Die DOS/Windows-Welt hatte schon immer eine komische Einstellung zu interpretierten Code. Man hat den zwar verabscheut, aber dann trotzdem die bizarrsten Systeme gemacht bei denen man sogar einen nicht menschenlesbaren Bytecode hatte, der interpretiert wird. (Visual Basic in frühen Versionen, .net, etc...) Somit kombiniert man die Nachteile von interpretierten Code mit den Nachteilen von Binärcode. Unter Unix wird interpretierter Code da verwendet, wo man ihn schnell ändern möchte. Der Bootprozess basiert beispielsweise bei den meisten unixoiden Systemen darauf. Interpretierter Code ist auch das was man macht, wenn man eben schnell mal ein Problem hat. Da die Konsole eine vollwertige (und ganz brauchbare) Programmiersprache ist, geht das ganz gut. Ich denke im Moment ist das größte Problem schlechtes Softwaredesign. Es gibt einfach Leute die glauben, je komplexer ein System ist um so besser, und dass sich Komplexität zur Optimierung immer lohnt. Somit werden die Programme teilweise 10 mal so groß, was jede Optimierung wieder eliminiert. Lies mal "The Art of Unix Programming" (gibts auch online) und Du liest eine informierte Meinung zu dem Thema.
Ein Unternehmen, welches so ineffizient arbeiten würde wie ein aktueller PC müßte 90-95 % seiner Leute entlassen. Bin mal gespannt, wie lange die sogennanten B(e)raterfirmen noch brauchen um das zu kapieren. gk
Hallo, Prozessorleistung ist eigentlich bei PCs nie das Problem. Nur stattet fast keiner die Kisten mit einem vernünftigem Plattensubsystem aus. Mit ner SSD geht alles gleich viel flotter. Nicht umsonst zählt man bei Datenbankrechnern schon seit Urzeiten die Plattenarme als wichtige Performancemetrik. Eckhard
So simpel und eindimensional ist das nicht und ein normaler PC hat selten die Zugriffscharakteristik eines grossen DB-Servers. Andererseits lassen sich auch DB-Server und OLAP-Systeme mittlerweile oft mit viel Speicher zähmen. Ob die dann aber mit vielen Cores etwas anfangen können ist eine andere Frage. Wer öfter mit Videobearbeitung und insbesondere Transcoding zu tun hat, der kann mit Prozessorleistung sehr wohl etwas anfangen, ebenso mit vielen Cores. Hingegen ist es bei Transcoding kaum relevant, wie schnell die I/O ist. Und dann wären da natürlich die Gamer. Ich bin da kein Experte, aber ich denke die Platte ist da nach der anfänglichen Laderei ziemlich wenig relevant. Dafür aber alles was viel Watt hat.
Stefan Helmert schrieb: > Man klickt etwas und es passiert mehrere Sekunden > lang nichts. Und wenn dann doch was losgeht, ruckelt erst mal der > Mauszeiger. Leuchtet/flackert währenddessen die HDD LED? Dann kauf Dir ne SSD.
Christian Berger schrieb: > Ich denke im Moment ist das größte Problem schlechtes Softwaredesign. Es > gibt einfach Leute die glauben, je komplexer ein System ist um so > besser Ja. Die meisten Kunden. Die kaufen nämlich lieber Komplexität als Stabilität. Letzteres wird als selbstverständlich kostenlose Update betrachtet. Gekauft wird Funktionalität aka Komplexität. Da der Verkäufer ab und zu mal frisches Geld braucht, bietet er eben immer weiter steigende Komplexität.
Ich sage auch schlecht programmierte Software (ganz sicher auch ein Compilerproblem oder auch Geldproblem) oder Strukturgrößen auf den DIE's müssen kleiner werden was in einem technischen Problem aber auf in einem finantiellen Problem liegt). Speicheranbindung muß besser werden (Technologien dafür sind bestimmt da aber wer wills bezahlen).... Technisch könnte man einen PC auf fast eine DIE bauen, ja ich weis , gibt es schon lange. Warum kauft sich der Thredersteller nicht einen PC der nur 20W braucht, dann hätte er den Thred auch nicht öffnen brauchen? Ich bin aber der Meinung, daß sich PC's in die richtige Richtung entwickeln! Die Technologie wird immer besser, auch weil bezahlbarer und wegen Fortschritt, denn z.B. schlechte Spannungswandler auf Board's tragen auch zur Ineffitienz bei. Leute lasst euch sagen "Wir sind das Problem" aber ich schreibe gerne darüber...
Ich dachte eben immer, dass wirklich Dinge falsch gemacht werden, die eigentlich nicht passieren sollen. Ich denke immer, dass Boolean-Daten immer gleich 64 Bit belegen. Ich kann mir auch vorstellen, dass einzelne Netzwerkanfragen mit: Send_Request(); while(0 == Get_Ack()); implementiert sind. Ich merke insbesondere Verzögerungen, wenn es ums Netzwerk geht. Bei Windows 7 kann man schon mal ein paar Sekunden Systemeinfrierung abwarten, bis die Netzwerkkonfig übernommen ist. Besonders lange dauert es auch sich mal die vorhandenen Wlans anzeigen zu lassen. Manchmal wird halt alles langsam, ohne CPU-Last und ohne Laufwerkzugriffe. Oft geht einfach eine Anwendung nach dem Update dieser ganz langsam. Ich habe immer noch ein altes VMWare (3.irgendwas). Die Version 4 war so langsam, dass das Gastsystem quasi nicht reagierte. Aber was wirklich schnell geht, sind die Dinge, die wirklich Rechenleistung brauchen: 3D, Codecs, usw. Ich denke immer Closed Source ist deshalb Closed Source, dass niemand sieht, wie schlecht etwas programmiert ist.
Stefan Helmert schrieb: > Ich denke immer Closed Source ist deshalb Closed Source, dass niemand > sieht, wie schlecht etwas programmiert ist. Wobei das kein Privileg von Closed Source ist. Auch bei Open Source kommt das vor. So hatte ich beispielsweise beim ARM-Zweig von GCC stellenweise den Eindruck, dass sich da keiner mehr an existierenden Code heran traut und notfalls lieber seinen eigenen kompletten Schwanz anfügt, auch wenns dadurch doppelt, dreifach und vierfach vorkommt.
Probier mal Gentoo, mit allen Befehlssatz-FLAGS für deinen CPU gesetzt, und installier nur LXDE, den X-Server und GDM ohne Compiz und anderen Klicki-Bunti Mist. Ich wette mit dir, dass die Kiste dann sofort auf alle Eingaben reagiert. Man muss dann eben die entsprechend schnellen Programme installiern z.B. Opera 9 als Browser. Getestet mit einer Pentium III Kiste mit 800MHz und 512 MB Ram. Reagiert auf Eingaben schneller als ein C2D mit Win7-Bloatware.
Stefan Helmert schrieb: > Hallo, > > der typischer Konsumer-PC mit Windows 7, Ubuntu 12.04 oder irgend so > einem MacOS oder wie das heißt scheint ja doch so lange es ihn gibt eher > als träge zu gelten. Man klickt etwas und es passiert mehrere Sekunden > lang nichts. Und wenn dann doch was losgeht, ruckelt erst mal der > Mauszeiger. Das liegt doch wenn eher daran, dass die von dir genannten Systeme sehr universell ausgelegt sind. Da laufen die unterschiedlichsten Prozesse im Hintergrund: Indizierung, Updates, Quickstarts und diverser anderer Kram, der zu jeder Zeit die unterschiedlichsten Dienste zur Verfügung stellen soll. Mit jeder neuen Hard-/Softwaregeneration kommen neue Dinge dazu, sodass es geradezu den Anschein hat, dass immer so viel mit reingepackt wird, dass es noch geradeso akzeptabel läuft. Es geht jedoch auch anders: Installier dir beispielsweise ein minimales Linux und pack dann nur das drauf, was du wirklich brauchst. Ich nutze solch ein Setup momentan auf einem i5 mit SSD, das kann man dann wirklich als flüssig bezeichnen. Da starten selbst Office-Programme innerhalb von ein bis maximal zwei Sekunden und man kann problemlos die ein oder andere VM nebenher laufen lassen. Bietet dann halt nicht ganz den universellen Komfort wie manch andere Systeme, da muss jeder für sich die Prioritäten setzen. Von daher finde ich, dass sich da in den letzten Jahren wirklich viel getan hat, die mögliche Performance ist spürbar besser geworden.
A. K. schrieb: > Um solchen die Performance steigernden und/oder die Kosten senkenden > Effekte in Form alter Software auf neuer Hardware entgegenzuwirken hat > man mittlerweile vorsorglich einen Riegel vorgeschoben. Versuch mal, ein > noch vergleichsweise verbreitetes System wie den Windows Server 2003 > direkt auf aktuellem Blech zu installieren. Nada, nichts geht mehr, > keine Chance. Stimmt, das muss eine Verschwörung sein. Undenkbar, dass es für aktuelle Hardware keine Treiber für alte Software (ja, 2003 ist lange her) gibt, weil es den Herstellern der Aufwand nicht wert ist.
Die Treiber gibts oft schon noch. Bei für Server typischer Hardware ist der Support besser als bei Desktops.
Stefan Helmert schrieb: > Man klickt etwas und es passiert mehrere Sekunden > lang nichts. Und wenn dann doch was losgeht, ruckelt erst mal der > Mauszeiger. Wenn das so sein sollte, dann solltest du dir mal nen modernen Rechner und ne SSD anschaffen... Das bei mir der Mauszeiger mal geruckelt hat, ist schon mindestens 10 Jahre her...
Vielleicht hat er ja mit Compact Flash auf IDE Adaptern angefangen ;-)
Christian Berger schrieb: > Somit kombiniert man die Nachteile > von interpretierten Code mit den Nachteilen von Binärcode. Das das eine Zwischenstufe ist (schneller als interpretierter Code und langsamer als Binärcode), ist dir aber nicht aufgefallen.
Es gibt da die sogenannte 110%-Regel. Sobald ein neuer Rechner mehr Leistung hat (mehr Speicher, schnellerer Prozessor etc.) wird diese auch genutzt. Programme werden umfangreicher und mit ineffizienten Strukturen aufgebläht, wo man früher einen Text geschrieben hat muß es heute ein Video sein und so weiter. Auch der Benutzer macht mit und installiert mehr als früher "weil es geht". Egal wieviel absolute Rechenleistung ein Rechner hat oder wieviel mehr relativ gegenüber dem Vorgänger, immer wird diese Leistung weiter und weiter ausgenutzt bis die Maschine zu 110% ausgelastet ist. Dann wird die Arbeit wieder so langsam daß man nichts mehr weiter draufpackt und darauf verzichtet noch mehr zu installieren. Das ganze funktioniert übrigens im Straßenverkehr genauso. Sobald eine neue Straße gebaut wird zieht sie den Verkehr an. Für kurze Zeit gibt es eine Entlastung, dann fahren genau so viel mehr Autos auf der bequemer gewordenen Strecke bis es wieder regelmäßig zu Staus kommt.
Leerer Bildschirm unter DOS: .COM-Datei mit 27 Byte oder so Leeres Fenster mit Delphi: 500kByte .EXE-Datei...
Oder das .NET Framework. Da installiert man sich runtimes mit hunderten MB Plattenplatz in verschiedenen (anscheinend nicht kompatiblen) Versionen... und das alles nur wegen ein paar simplen GUI Elementen... Der Windows Ordner müllt sich laufend mit Updates zu die natürlich auch alle gespeichert bleiben. Muss ich auch noch von der DLL HELL anfangen? ;-) Und im Laufe der Zeit sammelt sich sowieso ein riesen Berg Dateien auf dem Rechner wovon man vermutlich ein drittel auch einfach löschen könnte... aber wer nimmt sich schon die Zeit da mal aufzuräumen? ;-)
Schon der alte Wirth wusste, dass Software schneller langsamer wird als die Hardware schneller!
Hui schrieb: > Oder das .NET Framework. > Da installiert man sich runtimes mit hunderten MB Plattenplatz in > verschiedenen (anscheinend nicht kompatiblen) Versionen... > und das alles nur wegen ein paar simplen GUI Elementen... Nope, Du scheinst leider vom .NET Framework absolut keine Ahnung zu haben. In diesen hunderten MB Plattenplatz verbergen sich zehntausende von Routinen, welche im Alltag sehr nützlich sind, effizient programmiert und Softwareentwicklern je nach Projekt Jahre von mühseliger Fleissarbeit abnehmen. Mal schnell einen MD5 Hash berechnen? Ist schon drin! Mal schnell was über die RS232 Schnittstelle schicken? Ist schon drin! Mal schnell eine Matrix transformieren? Isch schon drin! Mal schnell eine UNDO/REDO Funktionalität einbauen? Ist schon drin! Mal eben in zehn Minuten eine effiziente Datenbankanbindung implementieren? Ist schon drin! Was ich sagen will; im .NET Framework ist ein gewaltiger Grundstock an Funktionalität drin, welchen man gar nicht mehr selber programmieren will und von seinen Kunden auch nicht bezahlt bekäme. Es bringt ja auch nichts, wenn jeder Softwareentwickler seine eigene MD5 Hash Berechnung selber programmiert. avr schrieb: > Christian Berger schrieb: >> Somit kombiniert man die Nachteile >> von interpretierten Code mit den Nachteilen von Binärcode. > Das das eine Zwischenstufe ist (schneller als interpretierter Code und > langsamer als Binärcode), ist dir aber nicht aufgefallen. Dieser Zwischencode (CIL) http://de.wikipedia.org/wiki/Common_Intermediate_Language wird ja bei der Programmausführung noch "fertig kompilliert". Daher sollte eine .NET Anwendung nach dem Start normalerweise nicht langsamen sein als "nativer Binärcode".
Johnny B. schrieb: > effizient programmiert Behauptung?! Johnny B. schrieb: > Es bringt ja auch nichts, wenn jeder Softwareentwickler seine eigene MD5 > Hash Berechnung selber programmiert. Richtig! Das man mit Java, .Not, C# schnell bestimmte Lösungen programmieren kann ist wohl ein alter Schuh, aber diese Schnelligkeit dann als Metrik für Effizienz zu benutzen das höhre ich immer nur von Programmierern/Nutzern der oben erwähnten Sprachen.
HutHut schrieb: > Das man mit Java, .Not, C# schnell bestimmte Lösungen programmieren kann > ist wohl ein alter Schuh, aber diese Schnelligkeit dann als Metrik für > Effizienz zu benutzen das höhre ich immer nur von Programmierern/Nutzern > der oben erwähnten Sprachen. Der Endanwender sieht ja meist auch nicht, mittels welcher Technologie ein Programm erstellt ist. Und es soll meiner Meinung nach auch so sein, dass es dem Endbenutzer ziemlich egal sein kann, ob eine Anwendung die er nutzt, nun mit Assembler, C, C++, Delphi, .NET, Java, Python oder sonstwas gemacht wurde. Hauptsache das Programm hält sich an die Bedienregeln der jeweiligen Plattform und funktioniert gut/zügig. Wenn eine Anwendung langsam ist, liegt es auch häufig daran, dass viel altes Zeug von zusammengekauften Firmen "zusammengefrickelt" wird und dann die Weiterentwicklung dieses Programmes aufgrund dieser krüppeligen Basis vorangeht. Das Protel / Altium Designer war früher so ein Beispiel, plötzlich poppte mal wieder ein Konsolenfenster auf und verschwand wieder und alles dauerte ewig.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.