App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Kernel 2.4.29 und A64 Unterstützung
- Ersteller Wuschl
- Erstellt am
Wuschl
Vice Admiral Special
Hallo!
Ich hätte gerna mal ein Problem, und zwar lässt sich bei meiner Slack 10.1 final der 2.4.29er Kernel nicht mit Athlon64 Unterstützung kompilieren, sondern speichert immer mit K7-Athlon Unterstützung ab und kompiliert entsprechend. Bei 10.1 RC1 gings noch
Und damit ihr meine Beweggründe versteht:
Im 32 bit Ati - Treiber fehlt die Unterstützung für den A64 Agp Controller und ich muß somit den Umweg über das externe Gart Modul gehen und das kostet Frames.
Spricht mein Kernel 64 Bit, so komme ich in den Genuß eines internen Gart Moduls.
Mache ich was falsch oder wie?
Gruß Wuschl
Ich hätte gerna mal ein Problem, und zwar lässt sich bei meiner Slack 10.1 final der 2.4.29er Kernel nicht mit Athlon64 Unterstützung kompilieren, sondern speichert immer mit K7-Athlon Unterstützung ab und kompiliert entsprechend. Bei 10.1 RC1 gings noch
Und damit ihr meine Beweggründe versteht:
Im 32 bit Ati - Treiber fehlt die Unterstützung für den A64 Agp Controller und ich muß somit den Umweg über das externe Gart Modul gehen und das kostet Frames.
Spricht mein Kernel 64 Bit, so komme ich in den Genuß eines internen Gart Moduls.
Mache ich was falsch oder wie?
Gruß Wuschl
Diablo
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 2.951
- Renomée
- 2
- Standort
- Passau
- Prozessor
- AMD Athlon XP Barton 2500+
- Mainboard
- Epox 8KRA2+
- Kühlung
- AMD Boxed
- Speicher
- 512 MB Samsung + 256 MB Infineon
- Grafikprozessor
- GeForce 5900XT
- Display
- Samsung SyncMaster 900SL
- HDD
- Maxtor 6B200MO (200GB, SATA) + 6Y160M0 (160GB, SATA) + Excelstor J880 (80GB, IDE)
- Optisches Laufwerk
- LG GSA-4120B
- Soundkarte
- SBLive! Player 1024
- Gehäuse
- Thermaltake Shark
- Netzteil
- Enermax Liberty 400W
- Betriebssystem
- Debian SID, Linux 2.6.15.1
- Verschiedenes
- Technisat SkyStar2 (DVB-S)
hmmm warum backst du dir nicht einfach einen 2.6er Kernel und versuchst es mit dem?
Wuschl
Vice Admiral Special
Original geschrieben von Diablo
hmmm warum backst du dir nicht einfach einen 2.6er Kernel und versuchst es mit dem?
Werd ich mal machen....
Original geschrieben von i_hasser
Also willst du einen 2.4er mit A64 GART Treiber oder einen 64Bit 2.4er Kernel? Letzteres ist bei Slack definitiv nur schwierig möglich.
Ich wollte einen 2.4er mit 64Bit Unterstützung um das interne Gart Modul des Ati Treibers nutzen zu können.
Was ich nicht verstehe: Mit Slack 10.1 RC1 gings ohne irgendwelche Probs. Aber scheinbar muß ich mich an dan 2.6er halten...
Gruß Wuschl
Also willst du einen AMD64 Kernel?
Dafür brauchst du einen GCC der in der Lage ist per Crosscompiling auch AMD64 Progs zu erzeugen, sonst kann das nicht gehen.
Sauber wird das in keinem Fall, da Slackware eigentlich eine reine i386 Distri ist... leider.
Dafür brauchst du einen GCC der in der Lage ist per Crosscompiling auch AMD64 Progs zu erzeugen, sonst kann das nicht gehen.
Sauber wird das in keinem Fall, da Slackware eigentlich eine reine i386 Distri ist... leider.
Wuschl
Vice Admiral Special
Hab's heute nochmal mit der 10.1 RC1 (die Version die den Kernel schon mal für "Hammer" kompiliert hat) probiert, und es ging nicht.... Komisch...
Na ich werde wieder mal sauber 32bittig installieren, schließlich will ich damit ja auch noch was arbeiten und nicht nur herumexperimentieren.
Gruß Wuschl
Na ich werde wieder mal sauber 32bittig installieren, schließlich will ich damit ja auch noch was arbeiten und nicht nur herumexperimentieren.
Gruß Wuschl
PuckPoltergeist
Grand Admiral Special
Original geschrieben von i_hasser
Also willst du einen AMD64 Kernel?
Dafür brauchst du einen GCC der in der Lage ist per Crosscompiling auch AMD64 Progs zu erzeugen, sonst kann das nicht gehen.
Nicht nur das, die binutils müssen das auch können. Linker und Assembler gehören nämlich mitnichten zum gcc.
Naja wie auch immer, es macht aber herzlich wenig Sinn einen AMD64 Kernel für ein IA32 OS zu benutzen, da wirst du sehr wahrscheinlich ein gutes Stück Performance verlieren, weil kein Prog nativ läuft.
PuckPoltergeist
Grand Admiral Special
Wieso langsamer, und wieso nicht nativ? Bei x86_64 wird nichts emuliert. Das, was dazu kommt, sind die 32bit-Systemaufrufe, die für 32bit-Anwendungen noch zusätzlich zur Verfügung gestellt werden müssen. Wo soll da so viel Performance verloren gehen?
PuckPoltergeist
Grand Admiral Special
Ich sehe da nicht, wo die Performance drauf gehen sollte. Wir können das aber gerne an Hand von Benchmarks klären.
Ich hab hier kein AMD64 Linux laufen, da Slackware eben eine IA32 Distri ist... leider .
Der direkte Vergleich ist auch nicht so ganz einfach, man müsste ein Prog nehmen, das viele OS Aufrufe generiert. Also ein einfacher Whetstone oder Dhrystone reicht da nicht aus.
Denkbar wäre irgendein schönes GUI Prog. Der Vergleich wird aber auch wegen AMD64 vs. IA32 nicht so einfach, den IA32 Code kann man auch nicht so ohne weiteres übersetzen, weil in AMD64 ja kein RegRenaming zur Verfügung steht (wäre schwierig bei 16 Regs).
Der direkte Vergleich ist auch nicht so ganz einfach, man müsste ein Prog nehmen, das viele OS Aufrufe generiert. Also ein einfacher Whetstone oder Dhrystone reicht da nicht aus.
Denkbar wäre irgendein schönes GUI Prog. Der Vergleich wird aber auch wegen AMD64 vs. IA32 nicht so einfach, den IA32 Code kann man auch nicht so ohne weiteres übersetzen, weil in AMD64 ja kein RegRenaming zur Verfügung steht (wäre schwierig bei 16 Regs).
PuckPoltergeist
Grand Admiral Special
Original geschrieben von i_hasser
Ich hab hier kein AMD64 Linux laufen, da Slackware eben eine IA32 Distri ist... leider .
Gentoo
Ich kanns also testen.
Der direkte Vergleich ist auch nicht so ganz einfach, man müsste ein Prog nehmen, das viele OS Aufrufe generiert. Also ein einfacher Whetstone oder Dhrystone reicht da nicht aus.
Och, mir fallen da gleich eine ganze Menge ein, die man dafür ran zeihen kann:
* Audio und Video encoden (oggenc, lame, mencoder...)
* povray
* compression/decompression (gzip, bzip2)
Der Vergleich wird aber auch wegen AMD64 vs. IA32 nicht so einfach, den IA32 Code kann man auch nicht so ohne weiteres übersetzen, weil in AMD64 ja kein RegRenaming zur Verfügung steht (wäre schwierig bei 16 Regs).
Welches RegRenaming meinst du, das was der Proz macht oder das vom Compiler? Du liegst hier aber bei beiden falsch.
Des weiteren weiß ich auch noch nicht so richtig, was du damit meinst, den IA32 Code nicht so ohne weiteres übersetzen zu können.
Original geschrieben von PuckPoltergeist
* Audio und Video encoden (oggenc, lame, mencoder...)
* povray
* compression/decompression (gzip, bzip2)
Das ist Quatsch, nix davon erzeugt ordentlich Aufrufe an das OS!
Welches RegRenaming meinst du, das was der Proz macht oder das vom Compiler? Du liegst hier aber bei beiden falsch.
Des weiteren weiß ich auch noch nicht so richtig, was du damit meinst, den IA32 Code nicht so ohne weiteres übersetzen zu können.
Nein, du liegst falsch. 1. nennt sich das was der Compiler macht nicht regrenaming, und 2. macht der A64 auf 16 Regs kein Renaming, wäre ein bisschen kompliziert und außerdem müsste man die Registerzahl für's Renaming deutlich erhöhen da sich selbiges eben auf 16 und nichtmehr 6 Regs bezieht.
Also entweder wird das Renaming sehr stark eingeschränkt bezüglich der Zahl der Schattenregs, oder komplett aufgegeben - was meines Wissens beim A64 der Fall ist.
PuckPoltergeist
Grand Admiral Special
Original geschrieben von i_hasser
Das ist Quatsch, nix davon erzeugt ordentlich Aufrufe an das OS!
Was sind bei dir ordentliche Aufrufe an das OS? Du musst dabei immer davon ausgehen, dass das noch messbar ist. Außerdem, bzip2 liest die zu komprimierende Datei zeichenweise ein. Für mich ist das schon einiges an Aufrufen.
PS: Um das zu testen, würden aber schon zwei Prozesse reichen, die sich permenant irgendwelche Nachrichten zuschicken, und darauf nicht wirklich arbeiten. Damit geht praktisch die gesamte Bearbeitungszeit nur für die syscalls bzw. die Prozessumschaltung drauf.
Nein, du liegst falsch. 1. nennt sich das was der Compiler macht nicht regrenaming, und
aus dem gcc-manual
-frename-registers
Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. It can, however, make debugging impossible, since variables will no longer stay in a “home register”.
Zumindest die gcc-Entwickler nennen es so.
2. macht der A64 auf 16 Regs kein Renaming, wäre ein bisschen kompliziert und außerdem müsste man die Registerzahl für's Renaming deutlich erhöhen da sich selbiges eben auf 16 und nichtmehr 6 Regs bezieht.
Also entweder wird das Renaming sehr stark eingeschränkt bezüglich der Zahl der Schattenregs, oder komplett aufgegeben - was meines Wissens beim A64 der Fall ist.
Dein Wissen ist scheinbar falsch. Der K8 macht das soger recht intensiv.
http://chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html
Zuletzt bearbeitet:
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 354K
- Antworten
- 0
- Aufrufe
- 234K
- Antworten
- 0
- Aufrufe
- 86K
- Antworten
- 0
- Aufrufe
- 75K