|
|
|
|
|
|
|
Unsere Geschichten wiederholen sich?
Was mich nicht so sehr wundert sind Schwierigkeiten mit zwei Grafikkarten, da ist jedes Betriebsystem, die Treiber und die Hardware eben nicht dafür entwickelt worden. Das sind alle Apple hinterher gerannt, aber die können eine abgestimmtes Lösung für genau ein Laptop erstellen und selbst dann ist es viellleicht nur oberflächlich elegant. Ich nehme stark an die dedizierte Grafikkarte ist nötig, also würde ich die interne im BIOS abstellen. Außer du bekommst damit, gerade bei diesen Lösungen haufig, einen Monitorausgang dann nicht zum Laufen oder so.
Ich hoffe bei uns komme sie wieder zur Besinnung, Gerüchte gab es. Weil Fujitsu viele nervt, kann man auch noch zusätzlich Dells bestellen. Anstatt einfach wieder Lenovo einzuführen, da hat niemand nach einer Alternative verlangt, die Server von Fujitsu waren nur billiger.
Was mich wundert, ist der Schocksensor:
Bei den ThinkPads wird der Trägheitsensor vom BIOS abgestellt, wenn keine HDD eingebaut ist. Ist also mit SSD nicht ansprechbar. Ich wollte den, wie einige andere, als reguläre Eingabe verwenden. Gab doch dieses Murmelspiel 
ThinkPads hatten Trägheitssensoren vor dem iPhone! Und eine Alarmanlage hat man, aus Spaß, auch implementiert.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 14.02.2018 23:57]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Außer du bekommst damit, gerade bei diesen Lösungen haufig, einen Monitorausgang dann nicht zum Laufen oder so.
| |
Das ist der einzige Grund warum wir Quadros haben. Ist die einzige Möglichkeit mehr als zwei Bildschirm anzusprechen. Die 3d Leistung brauchen wir gar nicht. Aber ja, die Monitore gehen dann halt trotzdem oft nicht 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
| | Zitat von hoschi
Außer du bekommst damit, gerade bei diesen Lösungen haufig, einen Monitorausgang dann nicht zum Laufen oder so.
| |
Das ist der einzige Grund warum wir Quadros haben. Ist die einzige Möglichkeit mehr als zwei Bildschirm anzusprechen. Die 3d Leistung brauchen wir gar nicht. Aber ja, die Monitore gehen dann halt trotzdem oft nicht
| |
ich hab hier letzte Tage zum ersten mal nen MST-Hub getestet. Geht zwar aktuell nicht mit Kram deutlich über 1080p, aber der Club3D 5300A kann z. B. 3 Monitore in FullHD über einen einzelnen DP-Ausgang ansteuern.
|
|
|
|
|
|
|
|
|
|
|
|
Jo, heute geht sowas. Das Aktuelle Gerät habe ich auch schon wieder über 2 Jahre. Was wir dann von der neuen Linie reinkriegen steht eh noch in den Sternen.
|
|
|
|
|
|
|
|
|
|
|
Wie befürchtet, Die aktuellen Intelchips sollten drei Monitor (alleine) ansteuern können, vor dem Hintergrund muss man wohl Daisy-Chaining mit DP sehen und dem Kabelsalat. Damit fällt dann eine mögliche Fehlerquelle auf Hardwareseite weg.
Wertungsfrei, Meson erfüllt fehlende Abhängigkeit. Mir gefällt es, das Meson lokal mit pkg-config die Abhängigkeiten auf berechenbare Weise erfüllt. Bei einer automatischen Auflösung der Abhängigkeiten habe ich immer Angst, wenn es richtig gemacht ist, kann das gut sein (lade Version x.y.z von Paket herunter, die Flags bitte!) oder eine Katastrophe wie bei Maven (lokal was altes, oder hier was vom Nexus aus der Firma, an dem hat aber wer rumgefummelt, ach neh, geht nur mit der Version von damals aus dem Internet...).
Abhängigkeiten manuell zu erfüllen ist richtig unangenehm, aber automatische Erfüllung gehört streng genommen nicht zu einem Buildtool.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 15.02.2018 15:11]
|
|
|
|
|
|
|
|
|
static_cast<csde_rats>(hoschi):
Apple und Textdarstellung. Oder wieder die Schreibkorrektur? Als ob das alles von einem rießigen Framework für alle Anwendungen gleichzeitig erledigt wird, ein einem Prozess.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 15.02.2018 15:46]
|
|
|
|
|
|
|
|
|
https://heise.de/-3969613 (Vorsicht: Link geht zu heise "make:")
| | | Dass Hardkernel erstmals einen Rechner mit Rockchip SoC konzipiert, hängt auch mit der Nachfrage von Usern nach besserer Linux-Unterstützung zusammen. | |
Lachflip. Was denn sonst? Die Anzahl der SBCs auf denen überhaupt irgendwas anderes als Linux läuft, kannste an einer Hand abzählen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das Hartkernel, du Schweinhund!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wer Deutsch spricht kann kein schlechter Mensch sein.
|
|
|
|
|
|
|
|
|
|
|
|
Weiß nicht. Bestimmt kommt gleich Rufus und sagt wieder was gemeines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...und der cronjob des Bösen hat wieder zugeschlagen.
|
|
|
|
|
|
|
|
|
|
|
Du hast SuSE-CDs gekauft!
/ zwipos haben Recht. Genau zur vollen Stunde.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Phillinger am 15.02.2018 22:05]
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
Deine vimrc ist Scheiße.
| |
Den muss ich mir merken
|
|
|
|
|
|
|
|
|
|
|
Ich habe eine Simulation in C geschrieben, die auf einem "i7-4930K CPU @ 3.40Ghz" doppelt so schnell läuft, wie auf meinem 3,6 bis 4 Ghz R5 1600X. Beide 6 Cores, 12 Threads.
i7: gcc 5.4 -O3 -fopenmp
real 2m32.658s
user 28m54.162s
sys 0m0.080s
R5: gcc 7.3 -O3 -fopenmp
real 5m1,557s
user 55m7,628s
sys 0m0,115s
beide mit -O2 oder -O3, die innerste loop mit openMP parallel-pragma.
what have I done?
/während ich getippt habe ist der Benchmark ohne openMP fertig geworden, ging schneller als gedacht.
i7: -O2
real 8m29.847s
user 8m29.853s
sys 0m0.000s
R5: -O2
real 4m53,762s
user 4m53,070s
sys 0m0,016s
Also ist meine CPU ohne openMP schneller?
Was zum Teufel?
|
|
|
|
|
|
|
|
|
|
|
|
Wieso die unterschiedlichen gccs?
|
|
|
|
|
|
|
|
|
|
|
Weil auf dem i7 ubuntu lts läuft, der steht im Labor.
Der R5 ist mein privater Rechner.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 16.02.2018 15:23]
|
|
|
|
|
|
|
|
|
|
K. Könnte halt durchaus nen Einfluss haben, wobei das bei dir schon heftig ist...
|
|
|
|
|
|
|
|
|
|
|
Wenn ich die auf dem i7 mit Ubuntu gcc 5 -O3 -fopenmp kompilierte Datei lokal ausführe:
real 2m49,036s
user 31m36,133s
sys 0m0,048s
the plot thickens...
|
|
|
|
|
|
|
|
|
|
|
Sicher, dass OMP in beiden Fällen gleich viele THreads genutzt hat, d.h. OMP_NUM_THREADS ist fix? Vergleiche bitte mal folgendermaßen:
| |
| Code: |
OMP_PROC_BIND=spread OMP_PLACES=cores OMP_DISPLAY_ENV=true OMP_NUM_THREADS=6 OMP_SCHEDULE=dynamic ./deine_sim |
|
/e: Und schau mal, ob es zwischen den OpenMP Versionen auf den Maschinen irgendwelche Unterschiede gibt, zum Beispiel, dass irgendwelche scheduling defaults oder so geändert wurden.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 16.02.2018 15:58]
|
|
|
|
|
|
|
|
| | Zitat von Rootsquash
Also ist meine CPU ohne openMP schneller?
Was zum Teufel?
| |
Beide sind schneller.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von red
| | Zitat von Rootsquash
Also ist meine CPU ohne openMP schneller?
Was zum Teufel?
| |
Beide sind schneller.
| |
Hm? Der i7 hat nur nicht perfektes Scaling. Aber ich finde 4 facher Speed auf 6 Cores schon ganz gut.
|
|
|
|
|
|
|
|
|
|
|
|
vergiss es, ich dachte, der Benchmark sei auch die komplette Simulation
|
|
|
|
|
|
|
|
|
|
|
Oli: Die openMP-Einstellungen festsetzen probiere ich gleich noch. Erstmal habe ich jetzt eine Schleife gebaut, die 3 mal neu kompiliert und jedes Mal 3 mal die Simulation laufen lässt.
schnellster Run:
(3,2)
real 3m8,997s
user 32m32,882s
sys 0m0,060s
direkt davor war der langsamste Run:
(3,1)
real 4m47,577s
user 50m57,613s
sys 0m0,054s
Ich werde da nicht schlau draus.
|
|
|
|
|
|
|
|
|
|
|
Bei so großer Varianz würde ich mir anschauen, ob du Bottlenecks wie {CPU-Kühlung, Mutex/Synchronisation zwischen Threads, I/O, Hintergrundanwendungen¹} hast.
Ein Blick mit nem Profiler (oder auch callgrind) kann sowas meist recht gut aufklären. Für Callgrind würde ich aber die Laufzeit deines Tests stark reduzieren, sonst ist das frühestens in ein paar Stunden fertig.
Wenn die Kiste sich nicht in irgendeinem Syscall oder Futex verheddert, dann wird's interessant. Je nach dem wie viel Code du da hast, würde ich mal probieren den Assembler der heißen Codeteile zu diffen.
¹ Anwendungen wie Firefox/Chrome/Thunderbird aus, kein Musik/Videoplayer, kein $HOME-Such-Indizierer, am besten auch nicht im Desktop rumklicken.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 16.02.2018 16:48]
|
|
|
|
|
|
|
|
|
Mein guess ist ja, dass bei dem einen Versuch nur ein omp Thread verwendet wurde, und bei der anderen 12. 
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
