|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
 |
|
|
|
|
|
|
|
Das kann sehr wohl nen Zusammenhang haben!
Als so etwa im Jahre 1998 die 400 und 450er AMD K6-2 rauskamen, gabs da ein Problem z.B. mit Win95! Ja, das startete nimmer! Stürzte einfach ab! Ausser, man taktete die CPU runter, spielte einen Patch und stellte danach den Takt wieder richtig ein!
Auch viele Programme, die mit Turbo-Pascal programmiert worden waren, versagten auf solchen CPUs den Dienst! Wieso?
Ganz einfach: Für gewisse Funktionen wurde ein delay-loop benutzt. Und der wurde beim Programmstart kalibriert. Man liess einfach ne gewisse Zeit den loop laufen und zählt, wieviel mal der durchlief!
Dazu wurde imho ein 16Bit Zähler verwendet! Tja, und bei 450MHz überlief der und das Programm deshalb nicht mehr!
Jetzt kommen vielleicht die 32-Bit Zähler dran!
--
auch die Zehe ist ein Laufwerk
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 15. July, 15:54 MES (#5)
|
|
|
|
|
Aber das ist ja definitiv auf schlampige
Programmierung zurückzuführen. Welcher Idiot
verwendet denn Delayloops? Meine Herren.
|
|
|
|
|
|
|
|
|
|
|
|
|
Früher[tm] hatte man IMHO keine andere Wahl...
|
|
|
|
|
|
|
|
|
|
|
|
|
> Früher[tm] hatte man IMHO keine andere Wahl...
:)) Das muss aber schon _sehr_ frueher gewesen sein, oder auf Rechnern die keinen Timer haben, was beim PC nicht zutrifft. Der andere Grund war, wenn man mit der Leistung so nah am maximal moeglichen ist das man nurnoch per CPU Takte das Timing machte - aber dann waren kaum Warteschleifen drinnen ... man hatte ja garkeine Zeit uebrig zum rumwarten.
Ein anderer Grund eine Warteschleife zu machen ist das man zu der Zeit einfach keine Timerresourcen hat, was z.B. waehrend der Bootphase eines OS vorkommen kann. Dann solle man aber die Schleifen so gross haben, das es zum einen keine vernuenftigen Grund zum ueberlauf gibt, zum anderen aber auch so codieren das moegliche Optimierungen keine rolle spielen (das war damals mit den AMDs das Problem). Tatsache ist das AMD (auch Intel und Motorola) bereits einige Verbesserungen an CPUs zuruecknehmen mussten, da es Ablaufprobleme mit Software gegeben hat die sich darauf verlassen hat das Befehle zeit brauchen. Wenn dann manchen Befehle glatt 'umsonst' waren ging nix mehr.
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Und aufm Duron gehts wieder:
LOOP wurde verlangsamt, sodaß der Fix nicht mehr nötig ist.
Also ist jetzt DEC/JNE schneller als LOOP...
--
mirabile, irc.ipv6.openprojects.net:6667 {#deutsch,#IceWM,#OpenBSD,#OpenBSD.de,#IPv6}
|
|
|
|
|
|
|
|
|
|
|
|
|
Also, der Artikel mutet schon etwas seltsam an.
Dass OSse (wie andere Programme auch) Probleme haben können, wenn die Prozessoren zu schnell sind, haben Win95 und viele Pascal-Programme hinreichend bewiesen.
Aber was in diesem Artikel da über Overclocking, zu hohe Spannungen und so geschriben wird (klar, das führt zu instabilitäten des Prozessors) und daraus die genannten Schlüsse zu ziehen, finde ich mehr als etwas seltsam!
Ich glaube, da muss ich mich doch meinem Vorschreiber anschliessen, dass hier mangels 1. April halt das Sommerloch an diesem Artikel schuld ist!
--
auch die Zehe ist ein Laufwerk
|
|
|
|
|
|
|
|
|
|
|
|
|
Diesen Gedanken hatte ich zuerst auch, aber nachdem ich mir den Artikel nochmals etwas genauer angeschaut hatte, fand ich eine Stelle wo bemerkt wurde, dass wahrscheinlich I/O-Requests zu zahlreich auf das OS "niederprasseln". Wir hatten ein ähnliches Problem 1996 mit Windows NT 3.51 und einer PCI-Netzwerkkarte, welche ebenfalls einen Stack im Betriebssystem überflutete.
--
Computers - born to use Linux!
|
|
|
|
|
|
|
|
|
|
|
|
|
Ähm, ja und? Wenn die CPU schneller wird, sollte sie auch mit häufigeren I/O-Requests schneller klarkommen - sprich, mehr verarbeiten können.
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
|
|
|
|
|
|
|
|
Die CPU vielleicht aber hier geht es, um das Betriebssystem und dieses schaft das vielleicht nicht.
Thomas
|
|
|
|
|
|
|
|
|
|
|
|
|
Hm, versteh ich trotzdem nicht. Ob nun 100/s reinkommen und 100/s verarbeitet werden können, oder 2000/s und 2000/s verarbeitet werden. Wobei ich mich fragen, warum es mehr I/O-Requests werden sollen, nur weil die CPU schneller läuft - im Gegenteil doch, es können mehr Befehle ausgeführt werden, bis der nächste Interrupt oder IO-Schrieb ansteht....
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
|
|
|
|
|
|
|
|
Vielleicht liegt es ja daran, daß der interne Optimierer der CPUs da einiges wirres Zeugs macht, die vorher nicht deutlich wurden und dadurch "Randeffekte", die in Win ausgenutzt werden, nicht mehr so auftreten?!
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
|
|
|
|
|
|
|
|
Tatsächlich ist natürlich Windows an sehr viel
altem Müll in x86 Prozessoren drin schuld; weil
ohne A20-Gate irgendwas nicht mehr laufen würde usf.
Das hat sich erst geändert seit die Consumer auch auf Windows NT/2000/XP umsteigen.
--
"The more prohibitions there are, The poorer the people will be"
-- Lao Tse
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[...] weil ohne A20-Gate irgendwas nicht mehr laufen würde usf. Das hat sich erst geändert seit die Consumer auch auf Windows NT/2000/XP umsteigen.
Das ist IIRC nicht richtig: In Intels 64-Bit Chip Itanium (und McKinley et al.) ist Gate A20 (und A40, was auch immer das tut) auch drin, aus Kompatibilitaetsgruenden!
Microsoft hat es anscheinend nicht fertiggebracht in den neueren und vorallem den 64-Bit Windowsversionen den A20-Kram loszuwerden ...
Besonders schlimm ist ja das Itanium und Co. eine neue ISA haben und trotzdem x86 Leichen eingebaut werden muessen :(
Ich kann mir aber auch gut vorstellen das Intel genervt ist ueber die "Ambitionen" von Seiten Microsoft alten Schrott in ihrer Software loszuwerden, aber Intel kann es sich halt nicht erlauben einen wichtigen Partner wie Microsoft zu veraergern. Hier haben die Anbieter mehr Moeglichkeiten die Soft- und Hardware selber produzieren (z.B IBM, Sun und Apple).
Gruss
Colin
|
|
|
|
|
|
