Re: Anfrage Multi-Prozessoren in FreeBSD

On Fri, Oct 28, 2011 at 11:57:25AM +0200, O. Hartmann wrote:
> On 10/27/11 14:33, Bernd Walter wrote:
> > On Thu, Oct 27, 2011 at 01:24:06PM +0200, O. Hartmann wrote:
> >> On 10/27/11 12:44, Bernd Walter wrote:
> >>> On Wed, Oct 26, 2011 at 11:36:11PM +0200, Colloid.Silver wrote:
> >> Das glaube ich nicht. Im Linuxumfeld hat sich in den vergangenen Jahren
> >> sehr viel getan und eigentlich ist Linux derzeit Vorreiter und in den
> >> BSDs, bis auf die Sicherheitsaspekte SSH wie in OpenBSD, werden
> >> architektonische Merkmale integriert, die aus anderen Entwicklungen
> >> stammen. Gerade im Hinblick auf HPC, wo sehr viel Wert auf
> >> Skalierbarkeit gelet wird, hat FreeBSD so gut wie nichts mehr zu melden.
> >
> > Die regelmässigen Anwendungsbenchmarks, die aus dem BSD-Team kommen
> > sprechen da eine ganz andere Sprache.
>
> Wo? Beispiele?

Da kommen öfters welche auf den internationalen Listen.
Müsste ich jetzt raussuchen, wozu mir leider gerade die Zeit fehlt.

> > Die Benchmarks aus dem Linux-Lager sind leider meistens geschönt und
> > haben mit realer Nutzung wenig zu tun.
>
> Was sind reale Nutzung? Webserver? Datenbanken? Oder andere Späße, für
> die man allenthalben eine Integer ALU braucht, aber keine FPU?

Neh im Sinne von Stromausfällen passieren bei Bei Benchmarks eh nie,
also brauchen wir keinen flush und ähnliches.
Die populärsten sind auch oft mit gepatchten und sonst wie getunten
Systemen, während man FreeBSD dann mit GENERIC ohne Patches oder
zumindest Einstellungen benutzt.
Das ist natürlich grundsätzlich schon irgendwo legitim.
Im FreeBSD Umfeld wird ja auch getestet ob ein Patch oder eine bestimmte
Einstellung was bringt, aber das wird dann auch entsprechend definiert.

> > Das fängt schon damit an, dass Linux selbst heute noch darauf verzichtet
> > auf SMP-Systemen eine monoton steigende Systemzeit zu bieten, während
> > Linux typische Spielzeugsoftware, wie MySQL hingegen immer noch extrem
> > oft eben diese Zeit abfragt - wozu, wo die doch unzuverlässig ist
> > weiß wohl keiner so genau.
>
> MySQl war auch im FreeBSD Umfeld stets eine Meßlatte und die letzten
> Benchmarks, die ich diesbezüglich gesehen habe, waren stets auf eine
> DB-optimierte Skalierung aus. Etwas, was ich leider im
> naturwissenschaftlichen Bereich gar nicht brauchen kann.

Gerade mit MySQL gibt es aber auch die Systemuhr Probleme.
MySQL ist auf Linux eben auch schnell, weil Linux dort schlampt und MySQL
diese schlampigen Ergebnisse dauernd anfordert.
Welchen Nutzen das macht sei dahingestellt.

> > Wenn du auf derartige billigen Tricks reinfallen willst - bitte schön,
> > das tun immerhin die meisten Menschen.
>
> Und Du bist die große Ausnahme?

Beim Toaster-kauf nicht.

> >> Mit dem Mangel an GPU-Unterstützung wird diese Kluft immer größer - sehr
> >> zu meinem bedauern.
> >
> > Das ist aber kein OS-Problem, sondern ein Problem der Hardwarehersteller,
> > die kein OpenSource unterstützen.
>
> Ist es. In FreeBSD fehlen wichtige Kerneleigenschaften, um es für die
> Treiberhersteller bequem zu machen, die entsprechenden Schnittstellen zu
> implementieren. FreeBSD ist durch den Mangel an KVM weit abgeschlagen!

Und genau weil das bei anderen OS besser ist gibt es das dort auch
nicht als OpenSource.

> Argumentiert wird stets, daß das mit dem Mangel an Entwicklern zu tun
> habe. Das ist dummer Unfug. Das ist nur ein kleiner Teil der Wahrheit.
> Gerade die auf Sicherheit drängenden BSD-Systeme würden einen großen
> Nutzen ernten, wenn KVM im Kernel implementiert wäre, da dann das
> graphische Subsystem nicht mehr via UID 0 (root) eingebunden werden
> müßte. Infolge dieser im Linux-Sektor massiv vorangetriebenen
> Entwicklung werden auch neue Treiberkonzepte, die mit der GPU als ein
> Rechengerät umgehen können, abgestimmt, die für FreeBSD, wie die anderen
> BSD Systeme auch, unerreichbar sind.

Also das meiste was die Linux-Entwickler vorantreiben ist leider ziemlicher
Bastelkram.
Erst recht wenn es um den ganzen grafischen Dreckskram geht.
Ein XOrg ist inzwischen leider nur noch für Bauchschmerzen gut.

> > Immerhin könnte FreeBSD mit seiner Lizens sowas nutzen.
> > Auch wenn das bislang nur vorwiegend bei Linux praktiziert wird ist
> > genau hier die Fragestellung offen, ob das wirklich mit der GPL in
> > Einklang steht.
>
> Ich glaube, das ist nicht naiv betrachtbar. Theoretisch ist mit der
> BSD/MIT Lizenz eine der wohl besten Lizenzen geschaffen worden, die sich
> ein souveränes und autarkes Staatengebilde wie die BRD vorstellen
> könnte. Und warum aber wird dann in Erwägung gezogen, Linux einzusetzen?
> Da wir auch eben jene Leute ausbilden müssen, die später mal als VWL,
> BWL oder Juristen in die "Entscheiderpositionen" kommen, kann ich ein
> Lied davon singen, was diese Leute an mathematisch-logischem Verständnis
> mitbringen. *Hüstel*

Das will ich ja nicht in Abrede stellen.
Ein Ubuntu ist auch sicherlich besser als Desktop für den Normaluser
geeignet als ein FreeBSD.
Auf meinem Accesspoint läuft auch ein OpenWRT - obwohl ich auch da
zwischendurch immer wieder kotzen könnte, vor allem weil man dem
DHCP-Server nicht bebiegen kann einen anderen DNS-Server zu liefern,
als seinen eigenen Proxy.
Und was in meinem Sat-Receiver für ein Flickwerk läuft will ich besser
gar nicht erst so genau wissen.

> > Das ist aber irelevant - der Vorteil von GPU-Leistung gegenüber
> > Anwendungsorientierte ist nur, dass die billig ist und zwar auch in
> > der Qualität.
> > GPU-Hardware hat keine Serverqualität, sondern ist Konsumerhardware.
> > Für Server gibt es spezialisierte Hardware - manche davon auch mit
> > FreeBSD-Support.
> > Und nein - es gibt keine spezialisierte Serverhardware mit FreeBSD-Support
> > zum errechnen von Bitcoins.
>
> Das zeigt mir, daß Du keine Ahnung von der Materie hast. ich sage nicht,
> daß ich Spezialist bin, aber wir arbeiten und Entwickeln mit CUDA und
> OpenCL Software, die leistungsoptimiert und hochparallel auf der GPU
> arbeitet. Modellierungen von Kollisionsprozessen, Wetter, Filter für
> immens große Bilddaten.

Ja und?
Früher hat man dafür Hardware designed - und ja davon _habe_ ich Ahnung.
Das geht auch heute noch und wäre technisch besser, aber eben auch teurer.
Klar - auch bei solchen Anwendungen gibt es Preisdruck und GPU sind
billiger, weil Mainstream-Hardware.
So lange aber wie man solche Geschichten mit GPUs als Kompromiss bastelt
wird es auch keinen Markt für angepasste Hardware geben.
Es bleibt euch daher nur der Zweckoptimissmuss, dass das keine Sackgasse
wird.

> Was hat eine GPU mit "Server" oder "Serverqualität" zu tun? Wichtig ist

Eben gar nichts - habe ich doch geschrieben.

> der "Server" als Entität, der mir als Anwender und entwickler und
> Forscher die Möglichkeit bietet, in angemessener Weise das gerät nutzbar
> zur verfügung zu stellen. Und FreeBSD kann das nicht. Leider. Aber es
> tut sich auch hier etwas. Man muß nur lange genug bohren!
>
> Und der Schwachsinn Bitcoin hat nun hier wirklich nichts zu suchen. Das
> soll im Resort der fachkundigen "Piraten" bleiben.

Es ist die gleiche Geschichte - nur ein weniger sinnvoller Anwendungsfall.
Es gibt Anwedungsfälle bei denen ein GPU missbraucht werden kann.
Sicherlich nicht ineffizient und vor allem billig.
Man denke nur an die kürzlich publizierte Crypto-Auslagerung auf GPU.
Ich würde denoch nie auf die Idee kommen einen Server mit einer fetten
GPU auszurüsten, um schneller zu crypten.
Zu C64-Zeiten hat man Apfelmänchen nicht nur im Rechner, sondern auch
auf dem Diskettenlaufwerk berechnen lassen.
War dafür nicht designed aber trotzdem gut geeignet und ohnehin vorhanden.
Hat es alles schon mal gegeben.
Nur hatte man damals noch alle technischen Unterlagen, was bei GPUs leider
nicht der Fall ist und es unterlag nicht den dauernden Generationswechseln.
Closed Source war zwar damals gebräuchlich, aber aufgrund der geringen
Komplexität kein besonderes Problem - auch das ist heute anders.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message