Llano - Desktop und Mobil, technische Aspekte

Danke Lynxeye!
Ein fundierter Vergleichstest wäre mal nicht schlecht ...
 
Dass ich als User dem System noch sagen muss dass meine SW vorrang hat vor dem was das System im Hintergrund treibt ist aber auch quatsch.
Schedulerlogik hin oder her.
Diese Klassifizierung gehört ins System. Und das ist 1 einzige if-Abfrage, sollte also auch nicht 100ms kosten.
 
Dass ich als User dem System noch sagen muss dass meine SW vorrang hat vor dem was das System im Hintergrund treibt ist aber auch quatsch.
Schedulerlogik hin oder her.
Diese Klassifizierung gehört ins System. Und das ist 1 einzige if-Abfrage, sollte also auch nicht 100ms kosten.

Für das System sind aber alle deine Prozesse gleich, denn das System treibt nichts im Hintergrund. Es sind alles Userspaceprozesse, welche gleich behandelt werden müssen.

Wenn du der Meinung bist, dass deine DNS Auflösung eine geringere Prio verdient, als dein Cinebench, dann stell es ein; wenn du denkst, dass sollte Voreinstellung werden, weils für alle Nutzer sinnvoll ist: melde es an deine Distri bzw. Microsoft.

Es gibt keinen vernünftigen Grund, warum ein Scheduler mehr Logik erhalten sollte, nur damit Sysadmins oder Userspaceentwickler um die sinnvolle Konfiguration ihrer Prozesse herum kommen.
 
http://translate.google.com/transla...68.com/a2011/0927/1252/000001252333_all.shtml



:o:o:o:o:o:o:o:o

Athlon X4 631@ 4,4 GHz @1,368 Volt und 170 Mhz Bustakt


Das sind ca. 70% Übertaktung ungefähr bei Llano Standarttakt.


b7c6e15f9ac935d1.png


411fef089406836c.png


1196f0d2c4695107.png
 
Zuletzt bearbeitet:
Für das System sind aber alle deine Prozesse gleich, denn das System treibt nichts im Hintergrund. Es sind alles Userspaceprozesse, welche gleich behandelt werden müssen.

Wenn du der Meinung bist, dass deine DNS Auflösung eine geringere Prio verdient, als dein Cinebench, dann stell es ein; wenn du denkst, dass sollte Voreinstellung werden, weils für alle Nutzer sinnvoll ist: melde es an deine Distri bzw. Microsoft.

Es gibt keinen vernünftigen Grund, warum ein Scheduler mehr Logik erhalten sollte, nur damit Sysadmins oder Userspaceentwickler um die sinnvolle Konfiguration ihrer Prozesse herum kommen.

Ich hab damit kein Problem, aber machen die OS nicht seit Generationen im Namen der "Benutzerfreundlichkeit" nicht genau das Gegenteil? - An allen Ecken und Kanten wird dem User das Denken abgenommen, man muss nichts mehr einstellen. Es läuft "Out of the box" - das ist doch auch genau der Punkt wo die Desktop-Linuxe hinwollen.
Warum ist das Mainstream-OS dann zu Dusselich seine Systemprozesse mit niedrigerer default-Prio zu starten?
Unter Linux gibts vieviele Nice-Level? 20?
Es war unter Kernel 2.4 Mode den X-Server mit Nice -10 zu starten, damit er deutlich höher Priorisiert ist als der Rest des Systems. Ergo könnte man genausogut die Startskripte so auslegen dass sie die Hintergrundprozesse auf einem Desktopsystem mit Nice 2 oder sowas starten, das wäre minimal niedriger priorisiert als normale Prozesse, aber im Zweifelsfall hätte mein Programmthread vorrang.
Analog könnte sowas unter Windows laufen. - Die Scheduler-Logik ist also bereits da, man müsste sie nur per default anders umsetzen.
Und ich rede dabei nicht von cinebench oder so Benchmark-Kram. Aber spätestens wenn ich ein Video gucke und das Ruckelt nur weil irgend ein blöder 0815 Hintergrundprozess der genausogut später noch laufen könnte, mir die CPU-Rechnezeit stiehlt, hat das nichts mit mehr Effizienz zu tun.
Die Hauptaufgabe eines PCs ist mir, dem Benutzer zu dienen und nicht dem System als solches. *noahnung*
Nun aber genug OT....
 
[...]
Ergo könnte man genausogut die Startskripte so auslegen dass sie die Hintergrundprozesse auf einem Desktopsystem mit Nice 2 oder sowas starten, das wäre minimal niedriger priorisiert als normale Prozesse, aber im Zweifelsfall hätte mein Programmthread vorrang.
[...]

Da teile ich deine Meinung. Die Frage über die hier diskutiert wurde war allerdings, ob der Scheduler intelligenter werden muss/kann. Und das ist eindeutig nicht der Fall. Das die Betriebssysteme insgesamt in dem Bereich besser werden müssen ist auch nicht zu bestreiten, deswegen der Verweis auf die Möglichkeit so etwas an die Distribution zu melden.

Bei den meisten gibt es nur immer diese Kurzschlussreaktion: der Scheduler ist für die Verteilung der Arbeit zuständig, die Arbeit wird nicht optimal verteilt (z.B. Kernhopping) -> großer Aufschrei, der Scheduler muss besser werden. Das ist einfach nur platt.
 
Ge0rgy: Zudem werden unter Linux (seit 3.0?) Prozesse in zwei Prozess-Gruppen gestartet: System-Prozesse in der ersten, User-Prozesse in der zweiten. So haben die User-Prozesse im Zweifelsfall (bei voller Beanspruchung) immer 50% der CPU-Ressourcen zu Verfügung, auch wenn nur 2 User-Prozesse gegen 100 System-Prozesse ankämpfen. Das dient in erster Linie dem Antwort-Verhalten.

Aber fragt mich jetzt nicht nach Quellen, notfalls müsste man die Kernel-Logs bei Heise durchforsten.
 
Ok, dann haben wir aneinander vorbeigeredet.
Ich wollte eigentlich darauf hinweisen dass die Scheduler intelligent genug sind, also die Strukturen bereits da. Dass wir diese nicht nutzen ist Dummheit/Faulheit/Nachlässigkeit/Ignoranz/<Bezeichnung bitte einsetzen>

Dazu ist Hardware einfach zu billig. Bevor man Entwicklerstunden für derariges "Tuning" opfert, kauft man lieber eine schnellere CPU und verlässt sich auf Moores Law. *noahnung*
.
EDIT :
.

Ge0rgy: Zudem werden unter Linux (seit 3.0?) Prozesse in zwei Prozess-Gruppen gestartet: System-Prozesse in der ersten, User-Prozesse in der zweiten. So haben die User-Prozesse im Zweifelsfall (bei voller Beanspruchung) immer 50% der CPU-Ressourcen zu Verfügung, auch wenn nur 2 User-Prozesse gegen 100 System-Prozesse ankämpfen. Das dient in erster Linie dem Antwort-Verhalten.

Aber fragt mich jetzt nicht nach Quellen, notfalls müsste man die Kernel-Logs bei Heise durchforsten.

Ist ja auch sinnvoll, der Kernel hat das Grouping ja auch erst kürzlich gelernt.
Imho geht der Ansatz in die richtige Richtung. Ist aber eben noch zu wenig verbreitet (un ich frage mich warum es erst 30 Jahre PC-Geschichte bedarf um auf so eine Idee zu kommen? ??? )
 
Ein Problem könnte sein wenn Programme selbst ihre Priorität festlegen, das man sich das System lockt weil einfach einer (absichtlich?) Scheiße baut oder einfach nur meint seine Software wäre am wichtigsten.

Letztlich ist die erwähnte Linux Methode am sinnvollsten, für mehr muss der User zu ständig sein. Ich kann mir zumindest keine sichere Methode vorstellen.
 
Du musst doch die Programme garnicht ändern... sondern nur dafür sorgen (über welche API auch immer) dass die Prozesse die sich als Systemdienste registrieren mit Nicelevel laufen, oder wie auch immer man das unter windoof nennt... eben eine Stufe weniger wichtig als die "normalen" Anwendungen.
*noahnung*
Da muss garkein Programm irgendwas selbst festlegen.
Das Sahnehäubchen wäre dann sowas wie Systemprozesse 2 stufen niedriger, minimierte Fenster eine stufe und das womit ich grade arbyte eben normalprio.
Dann hätte man das Chaos sortiert, Priorisiert und ich hätte manuell immer noch die Möglichkeit zu sagen "Programm xyz pinne ich auf höchste Prio, auch wenns im Hinterrund läuft weil...."
Aber dass der Flash-Update-Checker und die tausend kleinen "ich telefonier grad mal heim zum gucken was die Woche so los ist" - Routinen mir als Benutzer die Rechenzeit stehlen ist einfach nur autsch. *noahnung*
Nennt mich pingelig wenn ihr wollt. Aber wenn man schon um 10% Leistung hin oder her stundenlang diskutieren kann, wenn Benchmarks anhand von Zahlenwerten die sowieso eng beieinander liegen zerpflückt werden usw. Dann darf man auch mal die Effizienzkeule auspacken und sich fragen warum wir mit der Rechenzeit unserer CPUs so verschwenderisch umgehen. Oder besser gefragt, warum bin ich als zahlender Kunde, meine Wünsche und die Programme die ich grad bediene nicht wichtiger als irgend ein Hintergrundprozess xyz, den ich womöglich nicht mal kenne! *noahnung*
 
Wetten nur das Adobe sich sehr bemüht das Update-checker die bestmögliche Pri bekommt, genauso der HP Druckertreiber der seinen Tintenstand mitteilt.
Ich finde die Idee sogar sehr gut, aber zumindest unter Windoof würde man zu 100% probieren Schindluder zu treiben.
 
können sie das jetzt nicht auch? *noahnung*
 
Ich hab den Verdacht es ginge dann einfacher, aber du hast Recht um Missbrauch muss man sich so oder so Gedanken machen.
 
Jungs... Llano und Technische Aspekte heisst der Thread. Und Ihr seid nun schon über 2 Seiten an Schedulerverhalten/-Programmierung/etc. dran. Ist irgendwie ncht der Sinn dieses Threads.
Ich möchte hier Infos zu Llano finden, nicht zum Linux/Windows Scheduler.
Versteht mich nicht Falsch, das Thema ist sehr interessant, und es hat auch gute Ideen/Beiträge heir, aber könnt ihr dafür nciht einen eigenen Thread eröffnen?
 
"Here i come to save the dayyyyyyy" (http://www.funnyordie.com/videos/cc038c770a/andy-kaufman-performs-mighty-mouse-from-andykaufmanfan)


http://www.cpu-world.com/news_2011/...hipped_in_HP_PCs_New_Llano_core_revision.html


Ich würde mal sagen, dass sind doch exiting news: Eine kleine Revision (ob das als extra Stepping ausgewiesen wird, ist laut CPU-World nicht gesichert) kommt oder ist schon draußen, ein A4-3420 mit 2800 MHz kommt, und der Athlon II X4 631bekommt eine vorteilhaftere TDP-Einstufung, von jetzt 100 Watt auf 65 Watt. Der E2-3200 ist überdies auch lebendig wird momentan aber nur in HP-Geräten untergebracht.


via MSI: http://www.msi.com/product/mb/A75MA-G55.html#/?div=CPUSupport
 
Keine Ahnung, ob das spannend ist oder nicht, es ist vor Allem ON TOPIC.

Darüber hinaus könnte (u.U, vllt, wenn man es wagt zu spekulieren) eine geringere TDP-Einstufung auf bessere Yields hindeuten... muss sie aber nicht. Eine Minirevision finde ich aber doch spannend...wenn auch nur ein paar fixes gemacht werden, kann das der Ausbeute zuträglich sein... oder auch nicht.

Genaues weiß nur der Storch.
 
nun gut, aber "Core revisions" (Im cpu-world Artikel) deuten mindestens auf leichte Veränderungen am Design hin, nicht nur Verbesserungen im Fertigungsprozess. Von dem her müsste doch ein neues Stepping aufgegleist werden, oder mindestens eine neue Revision des Steppings, bsp B2a => B2b (Llano hat doch B2?).
Oder cpu-wold spekuliert nur und es sind die normalen Reifeprozesse bei der Fertigung. Mal schaun ;)

Auf jeden Fall begrüssenswert.

mfg memory_stick
 
Wo im besagten Link OEM-Systeme erwähnt werden: da tut sich tatsächlich etwas, allerdings in sehr sehr bescheidenem Rahmen. Hyrican und Wortmann zähle ich übrigens nicht zu den (relevanten, soll heißen weltweiten) OEMs.

Edit: sehe grad, dass das €300-Gerät mit E-350 ausgestattet ist, werd ich mal melden.
 
Zuletzt bearbeitet:
@ memory_stick

Bitte nicht Llano mit Bulldozer/FX verwechseln.


Llano ist B0 gestartet.


@ME

Klar kann das "nur" binning/Selektion (beziehe mich auf den 631) sein... aber warum dann die gleiche Bezeichnung, also keine Änderung außer bei der OPN?
 
Klar kann das "nur" binning/Selektion (beziehe mich auf den 631) sein... aber warum dann die gleiche Bezeichnung, also keine Änderung außer bei der OPN?
Das gibt's doch z.B. beim Phenom II X4 945 auch: mit 125W und 95W TDP. Da ist's ein anderes Stepping (C2 vs. C3), aber Llanos Prozess sollte ohne weiteres auch nen 65W-631 zulassen. Mehr dürfte der deutlich schnellere (2,9 vs 2,6 GHz) CPU-Teil des A8-3850 auch nicht verbraten, die restlichen 35W für die GPU.
 
Nö, den Phenom II 945 gabs auch in C2 mit 95 Watt TDP


http://www.cpu-world.com/CPUs/K10/AMD-Phenom II X4 945 - HDX945FBK4DGI (HDX945FBGIBOX).html

http://www.cpu-world.com/CPUs/K10/AMD-Phenom II X4 945 - HDX945WFK4DGI (HDX945WFGIBOX).html

Die 95 Watt Version war nur nicht (soweit ich weiß) für den Einzelhandel gedacht, das wurde dann mit dem hir gelöst:

http://www.cpu-world.com/CPUs/K10/AMD-Phenom II X4 945 - HDX945WFK4DGM (HDX945WFGMBOX).html


Mir ging es ja darum, dass es laut CPU-World kein wirklich neues Stepping ist sondern bei B0 verblieben wird... oder eben eine andere Version... mir fällt gerade ein, dass könnte auch auf eine Dual-Core Maske bei den A4ern/E2ern hinweisen... Trinity Desktop ist noch ein halbes Jahr entfernt... keine Ahnung ob das wirtschaftlichen Sinn macht, wahrscheinlich nicht.
 
Zuletzt bearbeitet:
130 { X86_VENDOR_AMD, 0x300f10 }, /* LN1_B0x */
131 { X86_VENDOR_AMD, 0x300f20 }, /* LN2_B0x */
*oink*

Wobei ich bei LN2_B0x immer von einem Dual Core die ausgegangen bin. Wobei GX und HX bisher eher nach einem Vertipper abgestempelt wurde, was bei AMD nicht wirklich was neues wäre, da strotzt alles von Tippfehlern.

keine Ahnung ob das wirtschaftlichen Sinn macht, wahrscheinlich nicht.
Wenn zu wenige halb defekte Dies vorhanden sind, macht es wahrscheinlich schon Sinn eine eigene Maske für die Dual-Core zu haben.
 
Zurück
Oben Unten