BSDForen.de  

Zurück   BSDForen.de > Sonstiges > Geplauder

Antwort
 
Themen-Optionen Thema bewerten Ansicht
Alt 04.11.2012, 12:41   #46
Azazyel
Registered User
 
Registrierungsdatum: Jun 2005
Beiträge: 388
Zitat:
Zitat von Lord_x Beitrag anzeigen
Naja zuzutrauen ist es den Jungs schon.
Der von darktrym verlinkte Vortrag wurde von einer Frau gehalten.

Zitat:
Zitat von Lord_x Beitrag anzeigen
Schliesslich haben sie KVM schon portiert.
KVM ist aber wesentlich überschaubarer (15k Zeilen Quellcode) und hat weniger (vor allem externe) Abhängigkeiten als die ganze Grafik-Mischpoke.

Ich gehe mal davon aus, dass sich das Team eher an der exitierenden Solaris-Infrastruktur denn einer Linux-API-Emulation orientieren wird, allein aus Gründen der verfügbaren Entwicklerkapazität. Weiß jemand Details?
Azazyel ist offline   Mit Zitat antworten
Alt 05.11.2012, 08:05   #47
christian83
Senior
 
Registrierungsdatum: Jul 2009
Beiträge: 378
Zitat:
Also man rühmt sich im ARM-Lager ja gerade eher damit, dass man einen Atom besiegt, der den doppelten Takt hat.
Ich finde das auch lustig, man ist stolz auf sich weil die stärkste ARM cpu den schwächesten x86 Prozessor schlägt... Das ist so was von toll ich bin mir sicher jetzt wird sich die Welt grundlegend ändern

Zitat:
AMD gehts gerade nicht besonders gut, einige Linux Entwickler (für die freien Parts) wurden bereits abgezogen.
Ich denke in Zukunft wird auch Intel weniger aktiv bei Linux sein. Intel ist ja ein Unternehmen das Geld verdienen will und wenn man für Linux irgendwelche freien Treiber entwickelt verdient man kein Geld. Man muss den Grund sehen warum Intel überhaupt bei Linux so aktiv ist. Bis vor einiger Zeit war Linux das einzige System welches im mobilen Bereich mit einer x86 cpu was anfangen konnte. Aber es waren alle Geräte bis auf ein paar Spielzeuge mit einer ARM cpu, man hatte dann auch noch Panik bekommen als Microsoft ankündigte zukünftig eine ARM Version anzubieten. Ich denke Intel hat versucht mit Linux ein eigenes System zu haben auf dem die eigene Hardware gut läuft so als art Notfallplan. Jetzt mit Windows 8 ist diese Einsatz in der Linux Welt im Grunde nicht mehr nötig und wird vermute ich mal auf lange Sicht eingeschränkt.

Zitat:
Die Lösung wird hier wohl eher in Richtig "Many-Core" zu suchen sein. So wie es Intel auch mit seiner Larrabee (GPU) versucht.
Ich vermute mal das zumindest im Desktop Bereich das Ende erreicht ist. Es wird bestimmt noch ein paar Mhz dort und einen Kern da mehr geben, aber große Sprünge wird es denke ich nicht mehr geben mit der aktuellen Technik. Es ist ja schön das fast jede Anwendung ihren eigenen Kern hat auf dem sie sich austoben kann, aber es gibt ja kaum Anwendungen die wirklich mehrere Kerne sinnvoll nutzen. Es gibt immer noch Anwendungen die auf einem Prozessor mit einem Kern und 3,6 Ghz schneller laufen als auf einem Prozessor mit 3 Ghz und 8 Kerne... Also da wäre noch Raum zum optimieren. Nur ob es Sinn macht wie bei GPU's hunderte Kerne zu haben weiß ich nicht. GPU's sind ja im Vergleich zu einer CPU eher simpel aufgebaut. Es gibt Hunderte Kerne aber meist sind diese auf eine Simple Aufgabe ausgelegt und können wirklich nur eine Gleichung rechnen und mehr nicht. Eine CPU muss mit jedem Kern alles können und die Jahre über hat sich auch eine Menge Müll angesammelt der aber noch immer unterstützt werden muss. Außerdem finde ich den Gedanken eines 500 Watt Pentiums etwas erschreckend... Da wäre beim Prozessor wohl neben dem Intel Aufkleber noch ein "Freundliche grüße: Ihr Energieversorger" Logo dabei

Bin mal gespannt was nach der x86 Generation kommt.

Grüße
__________________
jeegeek.cc
christian83 ist offline   Mit Zitat antworten
Alt 05.11.2012, 08:32   #48
Lord_x
Registered User
 
Benutzerbild von Lord_x
 
Registrierungsdatum: Jul 2012
Ort: /home
Beiträge: 264
Zitat:
Zitat von christian83 Beitrag anzeigen
Ich finde das auch lustig, man ist stolz auf sich weil die stärkste ARM cpu den schwächesten x86 Prozessor schlägt... Das ist so was von toll ich bin mir sicher jetzt wird sich die Welt grundlegend ändern
Es geht hier nicht nur um die Leistung sondern auch um den Stromverbrauch.

Zitat:
Zitat von christian83 Beitrag anzeigen
Ich denke in Zukunft wird auch Intel weniger aktiv bei Linux sein. Intel ist ja ein Unternehmen das Geld verdienen will und wenn man für Linux irgendwelche freien Treiber entwickelt verdient man kein Geld.
Intel verdient Geld damit, dass ihre Server gekauft werden, weil ihre Treiber so gut funktionieren.


Zitat:
Zitat von christian83 Beitrag anzeigen
Es wird bestimmt noch ein paar Mhz dort und einen Kern da mehr geben, aber große Sprünge wird es denke ich nicht mehr geben mit der aktuellen Technik. Es ist ja schön das fast jede Anwendung ihren eigenen Kern hat auf dem sie sich austoben kann, aber es gibt ja kaum Anwendungen die wirklich mehrere Kerne sinnvoll nutzen.
Ich rede von "Manycore" nicht "Multicore"! Hier sind mehrere 100 Cores gemeint. z.B. von Intel http://en.wikipedia.org/wiki/Larrabe...rchitecture%29
Lord_x ist offline   Mit Zitat antworten
Alt 05.11.2012, 19:40   #49
Yamagi
Possessed With Psi Powers
 
Benutzerbild von Yamagi
 
Registrierungsdatum: Apr 2004
Ort: Schleswig-Holstein
Beiträge: 6.552
Yamagi eine Nachricht über ICQ schicken
Naja, die Frage ist halt, was man will. Will man wenige schnelle Kerne oder viele, die dann aber weniger Leistung bringen? Beides mag seinen Sinn haben, je nach Workload. Aber das Eine wird nie das Andere ersetzen können... Und Manycore auf dem Desktop sehe ich noch nicht. Ich sehe es noch nicht einmal auf den meisten Servern. Vielleicht wird es sich ändern, aber im Moment ist es eine kleine Nische. Allerdings eine sehr profitable.

Und da sind wir wieder bei Intel vs. ARM. Hat ARM einen inherenten Vorteil gegenüber x86? Kaum. Zwar wird immer wieder über die "x86-Tax" durch die Decoder diskutiert, aber der Anteil der Decoder an der Chipfläche ist gering, ebenso ihr Stromverbrauch. Man gewinnt durch sie zudem weitere Optimierungsmöglichkeiten. Also unter dem Strich wohl ein Nullsummenspiel. ARM braucht einfach so wenig Strom, da es jahrelang dahin optimiert wurde. x86 wiederum wurde mindestens ebenso lange auf Geschwindigkeit optimiert. Ein schneller ARM-Prozessor wäre sehr wahrscheinlich kaum effizienter als ein moderner x86. Man bräuchte dort ebenfalls große Bussystem, riesige Cache-Hierarchieren, komplexe Uncores, etc. Das säuft Strom ohne Ende, die Kerne selbst verbrauchen da schnell nur noch einen Bruchteil des Powerbudgets. Umgekehrt wäre ein hochgradig verbrauchsoptimierter x86 auch nicht mehr schnell, weil halt vieles was Geschwindigkeit bringt, rausfliegen müsste. Und so dürften sich x86 und ARM nicht viel nehmen, wenn die derzeitige Trennung des Marktes aufgehoben werden sollte.

Da spielen dann andere Dinge eine Rolle und Intel hat in der Vergangenheit gezeigt, dass sie diese perfekt beherrschen. Es geht schon damit los, dass sich Intel immer weitgehend aus Bereichen herausgehalten hat, mit denen kein Geld zu verdienen ist. Was Intel im Quartal verdient ist gigantisch und vielleicht mehr, als die ganze ARM-Clique zusammen. Trotz einer viel geringen Stückzahl. x86 war nie die meistverkaufteste CPU-Architektur, aber es ist seit Ewigkeiten die profitabelste. Das bringt wiederum Geld in die Kriegskasse, womit man neue Technologien entwickeln kann, die noch mehr Geld bringen. Während die anderen strampeln, kann sich Intel erst einmal zurücklehnen und zuschauen.
Dazu kommen die unschöneren Dinge. AMD zum Beispiel hat sie sehr schmerzhaft lernen müssen. Sobald jemand Intel an die Cash-Cow will, wird die Firma gnadenlos und drängt den Konkurrenten notfalls auch mit klar illegalen Methoden aus dem Markt. Absprachen wie "Du verkaufst nur Intel und bekommst dafür Rabatt" sind nur die Spitze Eisbergs. Intel mögen in den klassischen ARM-Bereichen die Druckmittel fehlen, um diese Tour abziehen zu können, aber sobald ARM in Intels Territorium eindringt, sind sie da. In den ARM-Gefilden bleibt ihnen aber immer noch der Preiskampf, gerade in Märkten bei denen hundertstel Cent eine Rolle spielen, immer ein gutes Argument. Und da kann man mit etlichen Milliarden in der Kriegskasse einen verdammt langen Atem beweisen, sicher länger als fast alle anderen.

Ich sage klar, dass ich Intel nicht mag. Im Gegenteil. Ich habe diesen Verein immer verabscheut. Aber wenn ich wetten sollte, würde ich auf Intel setzen. ARM erinnert mich ein wenig an das AMD der 1990er. Es gab ein paar Achtungserfolge und vielleicht schafft man es nun, den Chipzilla kalt zu erwischen. Der Gegenschlag mag erst einmal auf sich warten lassen und es scheint, als würde Intel den Anschluss verlieren. Aber wenn er kommt, ist er mörderisch und es bleibt nur verbrannte Erde zurück. Man erinnere sich an 2006. Noch im Januar war AMD kurz vor dem Earnings-Crossover, dann kam der Conroe und einige Wochen später wurde die Firma an der Börse förmlich geschlachtet. Die ARM-Clique hat hier natürlich den Vorteil, dass es nicht nur eine Firma ist, sondern ein ganzer Schwarm. Und das ARM mehr als nur ein Produkt hat. Aber auch 300 Mücken bringen ein Pferd nicht um. Und so könnte es sehr gut sein, dass das Gleiche wie schon beim Alpha, beim PowerPC, beim SPARC und so weiter passiert. Das Intel zuletzt lacht und ARM wieder in der Nische verschwindet, aus der sie gekommen sind.

Das ist aber nun echt extrem Offtopic.
__________________
Eure Tastatur verfügt nicht umsonst über zwei Shift-Tasten! Benutzt sie bitte, denn sonst ist es mir fast unmöglich euere Posts zu entziffern.

Yamagi ist offline   Mit Zitat antworten
Alt 05.11.2012, 20:01   #50
christian83
Senior
 
Registrierungsdatum: Jul 2009
Beiträge: 378
Zitat:
Das Intel zuletzt lacht und ARM wieder in der Nische verschwindet, aus der sie gekommen sind.
Aber man kann sich sicher sein das irgendwann jeder seinen Meister finden wird, auch Intel. Viele Unternehmen die pleite gingen standen einige Monate ganz weit oben und wirkten unantastbar.

Zitat:
Die ARM-Clique hat hier natürlich den Vorteil, dass es nicht nur eine Firma ist, sondern ein ganzer Schwarm.
Wie ist das überhaupt, ARM vergibt doch nur Lizenzen zum bau/nutzung der Technik oder wie war das? ARM baut ja selbst keine Hardware so wie ich das verstanden habe...

Grüße
__________________
jeegeek.cc
christian83 ist offline   Mit Zitat antworten
Alt 10.11.2012, 09:14   #51
Lord_x
Registered User
 
Benutzerbild von Lord_x
 
Registrierungsdatum: Jul 2012
Ort: /home
Beiträge: 264
Zitat:
Zitat von Azazyel Beitrag anzeigen
KVM ist aber wesentlich überschaubarer (15k Zeilen Quellcode) und hat weniger (vor allem externe) Abhängigkeiten als die ganze Grafik-Mischpoke
Warum portiert man KVM dann nicht auf FreeBSD? Wegen der Lizenz? Ist es eigentlich sicher, dass FreeBSD in Version 10 einen eigenene Hypervisor bekommt? Weil jemand da etwas genaueres?

edit
WOW gerade das hier gesehen: http://retis.sssup.it/~fabio/freebsd/lkvm/

Da könnte ich kotzen echt! Warum kann man so ein "wichtiges" Projekt nicht fertig machen? Das ist so eine Sache, welche ich bei FreeBSD zum kotzen finde! Zig Projekte werden mit viel Einsatz gestartet und verlaufen sich dann ins Leere...
Lord_x ist offline   Mit Zitat antworten
Alt 10.11.2012, 09:31   #52
laemodost
FreeBSD User
 
Registrierungsdatum: May 2003
Ort: Düsseldorf
Beiträge: 1.704
laemodost eine Nachricht über ICQ schicken
Schade ist das auf jeden Fall.
Aber das war "nur" ein Summer of Code Projekt.
Ein Großteil der Projekte fließen nicht in FreeBSD ein, weil sie nicht fertig sind, weil der Style nicht stimmt, weil die Implementierung nicht dem Standard entspricht, etc.
Bei KVM wird es wohl auch so gewesen sein...
laemodost ist offline   Mit Zitat antworten
Alt 10.11.2012, 10:17   #53
Yamagi
Possessed With Psi Powers
 
Benutzerbild von Yamagi
 
Registrierungsdatum: Apr 2004
Ort: Schleswig-Holstein
Beiträge: 6.552
Yamagi eine Nachricht über ICQ schicken
Und weil oft kein Interesse besteht, die Sache langfristig zu pflegen.
__________________
Eure Tastatur verfügt nicht umsonst über zwei Shift-Tasten! Benutzt sie bitte, denn sonst ist es mir fast unmöglich euere Posts zu entziffern.

Yamagi ist offline   Mit Zitat antworten
Alt 10.11.2012, 12:19   #54
Lord_x
Registered User
 
Benutzerbild von Lord_x
 
Registrierungsdatum: Jul 2012
Ort: /home
Beiträge: 264
Zitat:
Zitat von Yamagi Beitrag anzeigen
Und weil oft kein Interesse besteht, die Sache langfristig zu pflegen.
Aber das ist doch eine Schlüsseltechnology in der heutigen Zeit!
Man hat so tolle Funktionen mit CARP, ZFS, GEOM, PF, HAST und den Ports. Macht sich aber durch die fehlende Virtualisierung eines anderen OS wieder zunichte.

Naja ist Offtopic das Thema.
Lord_x ist offline   Mit Zitat antworten
Alt 10.11.2012, 13:20   #55
lockdoc
Registered User
 
Benutzerbild von lockdoc
 
Registrierungsdatum: Feb 2005
Beiträge: 1.420
Offtopic:
Ich hab noch so duester im Hinterkopf, dass an XEN dom0 fuer FreeBSD gearbeitet wird oder gearbeitet werden soll
__________________
https://github.com/lockdoc
There would be less blood spilt in the battlefields if there were more sweat spent in the training hall.
lockdoc ist offline   Mit Zitat antworten
Alt 10.11.2012, 13:54   #56
peterle
Forenkasper
 
Registrierungsdatum: Aug 2006
Ort: Aachen
Beiträge: 702
Zitat:
Zitat von Lord_x Beitrag anzeigen
Aber das ist doch eine Schlüsseltechnology in der heutigen Zeit!
Man hat so tolle Funktionen mit CARP, ZFS, GEOM, PF, HAST und den Ports. Macht sich aber durch die fehlende Virtualisierung eines anderen OS wieder zunichte.

Naja ist Offtopic das Thema.
Die Frage ist halt, wer die Schlüsseltechnologie gerade dringend braucht und was ihm das wert ist.
__________________
grüße
peterle

---
Ich habe einen IQ unterhalb einer Kartoffel. Ich wusste nicht, dass man zum hier schreiben einen IQ oberhalb einer Kartoffel haben muss.
[Jana Heinze am 20.06.2002 in dspm]
peterle ist offline   Mit Zitat antworten
Alt 10.11.2012, 14:19   #57
Crest
rm -rf /*
 
Registrierungsdatum: Jun 2008
Ort: Bremen
Beiträge: 1.075
Komisch ich habe kein Bedürfnis meine FreeBSD Systeme in VMs zu stopfen. Jails reichen um Dienste von einander zu trennen. Ein Hypervisor darunter wäre in den meisten Fällen nur Verschwendung. Ich habe zum Glück keine Anwendungen mit HA Anforderungen, die nicht eigens dafür Unterstützung mitbringen.
Crest ist offline   Mit Zitat antworten
Alt 10.11.2012, 23:02   #58
Azazyel
Registered User
 
Registrierungsdatum: Jun 2005
Beiträge: 388
Zitat:
Zitat von Crest Beitrag anzeigen
Komisch ich habe kein Bedürfnis meine FreeBSD Systeme in VMs zu stopfen.
Ich habe das Bedürfnis, fast alles in VMs zu stopfen.

Zitat:
Zitat von Crest Beitrag anzeigen
Jails reichen um Dienste von einander zu trennen.
Das eine schließt das andere nicht aus.

Zitat:
Zitat von Crest Beitrag anzeigen
Ein Hypervisor darunter wäre in den meisten Fällen nur Verschwendung.
In meiner Erfahrung überwiegt der Zugewinn an Flexibilität die wenigen Prozent Performance-Verlust bei weitem. Zumal man durch Virtualisierung insgesamt deutlich weniger Hardware benötigt.

Zitat:
Zitat von Crest Beitrag anzeigen
Ich habe zum Glück keine Anwendungen mit HA Anforderungen, die nicht eigens dafür Unterstützung mitbringen.
Selbst ohne HA-Anforderungen ist Virtualisierung genial.

Die Hardware macht Zicken? Einfach die VM auf eine andere Maschine verschieben und in aller Ruhe die Hardwareprobleme offline lösen.

Ein Software-Upgrade steht an? Vorher einen Snapshot erstellen; geht etwas schief, muss man nicht lange ein Backup einspielen, sondern hat in Sekunden den alten Systemstand wiederhergestellt - unabhängig von den beteiligten Betriebssystemen.

Ein Testsystem wird benötigt? Ein paar Tasten bzw. Knöpfchen drücken und man kann das Setup mit 3 Rechnern in 2 unterschiedlichen Netzwerken testen - auf dem Laptop.
Azazyel ist offline   Mit Zitat antworten
Antwort


Dieses Thema betrachten zurzeit 1 Personen. (0 registrierte Benutzer und 1 Gäste)
 
Themen-Optionen
Ansicht Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist An.
Smileys sind An
[IMG] Code ist An
HTML-Code ist Aus
Gehe zu


Alle Zeitangaben in WEZ +1. Es ist jetzt 23:06 Uhr.


Powered by vBulletin (Deutsch)
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.