Prozessorleistung einst und jetzt (was: Linux-Neuling)

[Diedrich Ehlerding]

Ulli Horlacher meinte:

>>> DAS klingt mir nun eher nach ein konzeptionellem Problem :-)
>>> Zu meiner Studi-Zeit hat DER Zentral-Computer 12 MB RAM und es
>>> reichte fuer ALLE. Gleichzeitig. Interaktiv.
>>
>> Na ja - die konnten damit auch nicht viel machen.
>
> Es reichte fuer (fast) alle wissenschaftliche Anwendungen einer
> grossen Universitaet.
> Es gab nur noch wenige zusaetzliche Spezial-Workstations in den
> Instituten, hauptsaechlich fuer Grafik.

Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
Größenordnungen höher ist als damals für die ganze Uni reichte. Die
Briefe, die man heute auf dem Computer schreibt, werden aber nicht
schneller fertig als damals an der Schreibmaschine - sie werden nur
bunter und schöner.

Andererseits erinnere ich mich an einen Vortrag (um 1980 rum), in dem
jemand über einen Vektorrechner berichtete (wenn ich mich recht
erinnere, eine Maschine von CDC), damals ein Wunderwerk der Technik, der
dann, wenn die Anwendung eben vektorisierbar war (aber auch nur dann)
für seine Zeit gigantische Rechenleistungen von einigen 100 MFlops
erreichte. Zum Beispiel hatte der deutsche Wetterdienst wohl so eine
Maschine.

Was mit in Erinnerung geblieben ist aus dem Vortrag, war der Hinweis,
dass bei entsprechend komplexen Problemen Rechenleistung so gut wie nie
ausrecht - das Beispiel war damals die Wettervorhersage, bei der ein
dreidimensionales Gitter von Datenpunkten als Näherung für die
Atmosphäre bereitgestellt wird. Der Vortragende sagte damals ungefähr
"unsere Klimamodelle sind heute [also damals] so, dass wir mit unserer
Hardware die Chance haben, ein Gitter mit einer Kantenlänge von 10 km
waagerecht und 100 m vertikal zu berechnen und die Temperatur auf +-2°.
Die Landwirte bräuchten aber, etwa im Zusammenhang der Frage 'wo muss
ich Wasser versprühen, um meine Obstbaumblüten vor Frost zu schützen',
eine Auflösung von möglichst 100 m horizontal und 10 m vertikal, das
macht also den Faktor 10^5 in der Zahl der Gitterpunkte, und dazu kommt
dann die Temperaturgenauigkeit, und die Gleichungssysteme, die wir da
berechnen, haben eine Komplexität O(x^2) oder O(x^3), d.h. - einen
milliardenfach schnelleren Prozessor hätten wir gern, und natürlich auch
einen milklionenfach größeren Hauptspeicher".

(Ich lenke um; hat nix mehr mit Linux zu tun, nur noch mit Nostalgie)
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Michael Kraemer]

On 10.01.2024 16:32, Diedrich Ehlerding wrote:

>
> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
> Größenordnungen höher ist als damals für die ganze Uni reichte. Die
> Briefe, die man heute auf dem Computer schreibt, werden aber nicht
> schneller fertig als damals an der Schreibmaschine - sie werden nur
> bunter und schöner.

Und auch bei "richtigen" Anwendungen wird man nicht schneller fertig
wenn mehr Rechenleistung da ist.
Man erfindet dann grössere Problemstellungen und wartet am Ende
doch wieder Stunden oder gar Tage auf das Ergebnis.

[Marco Moock]

Am 10.01.2024 um 16:31:13 Uhr schrieb Stefan Ram:

> Ähnlich empfinde ich es bei der Kapazität von Festplatten.

Da gab es die doch mehrfach. Überlege mal, eine Platte von 1995 hatte
~500 MB, eine aus 2015 hatte problemlos 1000 GB.
Beides in normalen PCs der damaligen zeit verbaut.

[Kay Martinen]

Am 10.01.24 um 17:17 schrieb Michael Kraemer:

> On 10.01.2024 16:32, Diedrich Ehlerding wrote:
>
>>
>> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
>> Größenordnungen höher ist als damals für die ganze Uni reichte. Die
>> Briefe, die man heute auf dem Computer schreibt, werden aber nicht
>> schneller fertig als damals an der Schreibmaschine - sie werden nur
>> bunter und schöner.

Und verschwenden mehr... von allen Ressourcen.

> Und auch bei "richtigen" Anwendungen wird man nicht schneller fertig
> wenn mehr Rechenleistung da ist.

Effizienter Briefeschreiben geht eben nur mit "KI" [Aktuelle Sau im Dorf] :)

Klar, Ich schaffe mir gleich einen Virtuellen Briefkasten in "Cloud
Seven" an.

> Man erfindet dann grössere Problemstellungen und wartet am Ende
> doch wieder Stunden oder gar Tage auf das Ergebnis.
>

Irgendwie mußte ich an ein Altes Franzis RPB Buch denken, über den Laser.

"Der Laser ist eine Technologie die noch nach einer Anwendung sucht"

Stand dort - aus der Frühzeit der Erforschung.

Sicher ist nur eines. Die Anwendungen WERDEN gefunden wenn die
Möglichkeiten erst da sind. Klimamodelle, Uni-Mainframe, Laser,
Vorratsdatenspeicherung, Chatkontrolle, etc. ppp.

<ironie> Es wäre ja schließlich auch "sträflicher Leichtsinn" gewesen
den Deutschen damals die Forschung zu überlassen... dann lieber selbst
machen, bauen und... bis heute sind die USA das einzige Land das
Nuklearwaffen auf ein anderes abgefeuert hat. </ironie>

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Kay Martinen]

Am 10.01.24 um 17:31 schrieb Stefan Ram:

> Diedrich Ehlerding <diedrich....@t-online.de> writes:
>> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
>> Größenordnungen höher ist als damals für die ganze Uni reichte.
>

> Ja. Allerdings werden die Wachstumsraten, die man für einzelne
> Kerne hat, seit 2005 kaum noch größer. Herb Sutter schrieb
> etwas zu diesem Thema in Dr. Dobb's Journal, 30(3), March 2005.
>
> Wir kamen von dem 1-MHz-6502 zu Prozessoren mit 1 GHz, sagen wir um
> das Jahr 2000 herum. Solch eine Vertausendfachung der Taktfrequenz
> haben wir seitdem nicht einmal nährungsweise wieder erlebt.

Jetzt fehlt doch noch eine Vertausendfachung des Durchsatzes beim
Nadelöhr Arbeitsspeicher. Oder; noch heftiger; beim Durchsatz zu
Massenspeichern.

Stell dir vor was das für Auswirkungen hätte?

[Marcel Mueller]

Am 10.01.24 um 17:17 schrieb Michael Kraemer:

> Und auch bei "richtigen" Anwendungen wird man nicht schneller fertig
> wenn mehr Rechenleistung da ist.
> Man erfindet dann grössere Problemstellungen und wartet am Ende
> doch wieder Stunden oder gar Tage auf das Ergebnis.

Nach meinen Erfahrungen wird Software immer so programmiert, dass sie
den gut ausgestatteten Rechner des Entwicklers nicht völlig lahm legt.
Auf dem Rechner der User funktioniert das nur deswegen einigermaßen gut,
weil der zwei Jahre später, wenn er das Produkt auf seiner Kiste hat,
mindestens gleichschnell ist.


Marcel

[Hermann Riemann]

Am 10.01.24 um 16:32 schrieb Diedrich Ehlerding:

> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
> Größenordnungen höher ist als damals für die ganze Uni reichte. Die
> Briefe, die man heute auf dem Computer schreibt, werden aber nicht
> schneller fertig als damals an der Schreibmaschine - sie werden nur
> bunter und schöner.

Suche mal nach Vergleich Cray gegen raspberry pi.

[Hermann Riemann]

Am 10.01.24 um 18:10 schrieb Kay Martinen:

>>    Wir kamen von dem 1-MHz-6502 zu Prozessoren mit 1 GHz, sagen wir um
>>    das Jahr 2000 herum. Solch eine Vertausendfachung der Taktfrequenz
>>    haben wir seitdem nicht einmal nährungsweise wieder erlebt.

Das Problem dabei ist die Wärmeabfuhr.
Was war der 68000 noch so kühl.

> Jetzt fehlt doch noch eine Vertausendfachung des Durchsatzes beim
> Nadelöhr Arbeitsspeicher. Oder; noch heftiger; beim Durchsatz zu
> Massenspeichern.

Mit optischer Datenübertragung mittels Laser Dioden und
und 3D Digitalkameras..

> Stell dir vor was das für Auswirkungen hätte?

Hohe Temperaturen und Programmierprobleme.


--
<http://www.hermann-riemann.de>

[Gerrit Heitsch]

On 1/10/24 18:10, Kay Martinen wrote:
> Am 10.01.24 um 17:31 schrieb Stefan Ram:
>> Diedrich Ehlerding <diedrich....@t-online.de> writes:
>>> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
>>> Größenordnungen höher ist als damals für die ganze Uni reichte.
>>
>>    Ja. Allerdings werden die Wachstumsraten, die man für einzelne
>>    Kerne hat, seit 2005 kaum noch größer. Herb Sutter schrieb
>>    etwas zu diesem Thema in Dr. Dobb's Journal, 30(3), March 2005.
>>
>>    Wir kamen von dem 1-MHz-6502 zu Prozessoren mit 1 GHz, sagen wir um
>>    das Jahr 2000 herum. Solch eine Vertausendfachung der Taktfrequenz
>>    haben wir seitdem nicht einmal nährungsweise wieder erlebt.
>
> Jetzt fehlt doch noch eine Vertausendfachung des Durchsatzes beim
> Nadelöhr Arbeitsspeicher.

Hatten wir doch... Hier steht ein Rechner, nicht ganz neu, dem
memtest86+ einen Speicherdurchsatz (nicht Cache!) von 17 GB/sec
bescheinigt. Der 1 MHz 6502 hatte deutlich weniger... 2 MB/sec, davon
die Hälfte für den Videocontroller.

Ansonsten haben Grafikkarten oft sehr hohen Speicherdurchsatz, aber eben
nicht bei jeder Anwendung.

Gerrit

[Arno Welzel]

Marcel Mueller, 2024-01-10 18:43:

Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
Das ist keinesfalls immer gegeben.

--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Kay Martinen, 2024-01-10 18:10:

> Am 10.01.24 um 17:31 schrieb Stefan Ram:
>> Diedrich Ehlerding <diedrich....@t-online.de> writes:
>>> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
>>> Größenordnungen höher ist als damals für die ganze Uni reichte.
>>
>> Ja. Allerdings werden die Wachstumsraten, die man für einzelne
>> Kerne hat, seit 2005 kaum noch größer. Herb Sutter schrieb
>> etwas zu diesem Thema in Dr. Dobb's Journal, 30(3), March 2005.
>>
>> Wir kamen von dem 1-MHz-6502 zu Prozessoren mit 1 GHz, sagen wir um
>> das Jahr 2000 herum. Solch eine Vertausendfachung der Taktfrequenz
>> haben wir seitdem nicht einmal nährungsweise wieder erlebt.
>
> Jetzt fehlt doch noch eine Vertausendfachung des Durchsatzes beim
> Nadelöhr Arbeitsspeicher. Oder; noch heftiger; beim Durchsatz zu
> Massenspeichern.

NVMe-SSDs sind schon bei mehr als 3 GB/s angekommen. Damit schreibt man
1 TB Daten in weniger als 10 Minuten voll.

Und DDR5-RAM erreicht auch schon über 50 GB/s. Selbst DDR4 kommt schon
auf über 30 GB/s.

Der 6502 schaffte mit 1 Mhz rechnerisch maximal 500 KB/s, da ein NOP 2
Taktzyklen braucht. Schneller können Daten mit dem 6502 nicht aus dem
RAM gelesen werden. Wenn ich nicht völlig falsch rechne, ergibt das
gegenüber 50 GB/s Faktor 100.000, also weit mehr als Faktor 1000.

> Stell dir vor was das für Auswirkungen hätte?

Reicht Dir das, was ein aktueller PC kann, nicht?

[Andreas Kohlbach]

On 10 Jan 2024 16:31:13 GMT, Stefan Ram wrote:

>
> Diedrich Ehlerding <diedrich....@t-online.de> writes:
>>Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
>>Größenordnungen höher ist als damals für die ganze Uni reichte.

Und einen "Apollo-Computer" hat man seit Jahrzehnten in seiner
Hosentasche.

> Ja. Allerdings werden die Wachstumsraten, die man für einzelne
> Kerne hat, seit 2005 kaum noch größer. Herb Sutter schrieb
> etwas zu diesem Thema in Dr. Dobb's Journal, 30(3), March 2005.
>
> Wir kamen von dem 1-MHz-6502 zu Prozessoren mit 1 GHz, sagen wir um
> das Jahr 2000 herum. Solch eine Vertausendfachung der Taktfrequenz
> haben wir seitdem nicht einmal nährungsweise wieder erlebt.

Da erinnere ich mich an die späten 90er, als Hobbyisten mit
Flüssigkeits-Kühlung versuchten, eine XXX MHz mit 1 GHz zu takten. Und
die Bilder dazu. Die zeigten einen Computer mit vielen Schläuchen, als ob
er an ein Lebenserhaltungssystem einer Notaufnahme angeschlossen war.

Um 2005 scheint mir auch das Ende der Fahnenstange erreicht gewesen zu
sein, was die Leistung *einer* CPU anbetraf. Dann gab es eigentlich nur
noch immer mehr Kerne in /einer/ CPU. Auch wenn Betriebssysteme jeden Kern
als eigene CPU listen.

[...]
--
Andreas

[Markus Elsken]

Moin!

Am 10.01.24 um 18:10 schrieb Kay Martinen:

> Jetzt fehlt doch noch eine Vertausendfachung des Durchsatzes beim
> Nadelöhr Arbeitsspeicher.

Wie war der Durchsatz bei einem alten 8-Bitter unter 1MHz und was
schafft heute Epyc 9754 mit seinen 12 DDR5-Kanälen?

> Oder; noch heftiger; beim Durchsatz zu
> Massenspeichern.

Floppy, Datasette, Lochstreifen? Oder doch schon eine MFM-Platte (wenn
alles optimal lief ca. 500kB/s bei Interleave 1) gegen ein RAID aus 16
oder 24 PCIe-SSDs (PCIe5x4, also 15,75GB/s x16 bzw. x24)?

mfg Markus

[Stefan Möding]

Arno Welzel <use...@arnowelzel.de> writes:

> Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
> Das ist keinesfalls immer gegeben.

Da läuft die Anwendung ja auch nur mit 5 Demo-Datensätzen.
Dafür reicht es dann ja auch.

--
Stefan

[Marcel Mueller]

Am 10.01.24 um 22:57 schrieb Arno Welzel:

> Marcel Mueller, 2024-01-10 18:43:

>> Nach meinen Erfahrungen wird Software immer so programmiert, dass sie
>> den gut ausgestatteten Rechner des Entwicklers nicht völlig lahm legt.
>> Auf dem Rechner der User funktioniert das nur deswegen einigermaßen gut,
>> weil der zwei Jahre später, wenn er das Produkt auf seiner Kiste hat,
>> mindestens gleichschnell ist.
>
> Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
> Das ist keinesfalls immer gegeben.

Der Entwickler hat nicht die neueste, aber zum Kaufzeitpunkt gut
ausgestattete Hardware, denn die Entwickertools sind wahrlich keine
Kostverächter.
Aber die meisten Entwickler, die ich kenne (und das sind einige) achten
überhaupt nicht darauf, welche Datenstrukturen sie verwenden, und es ist
ihnen auch vollkommen egal, ob dabei in jedem Schleifendurchlauf nochmal
der gesamte Arbeitsvorrat durchsucht wird, also quadratische
Komplexität. Erst wenn eine Stelle wirklich ein Problem macht, wird
optimiert.

Es gibt eine alte Entwickler-Regel: first make it work, then make it
fast. Die produziert genau jene, verbreitete Software, die alle zum
Entwicklungszeitpunkt verfügbaren Systemressourcen effizient verbraucht.
Und wenn man berücksichtigt, dass "make it fast" nicht selten bedeutet
"wegschmeißen und neu machen", ist die vermeintliche Ersparnis durch
diese Vorgehensweise auch gar nicht mehr so groß.

Das ist halt eine ökonomische Sache. Die Entwickler bezahlt der
Softwarehersteller, das Blech (Rechner) bezahlt der Kunde, also
Ressourcenverbrauch egal.

Es gibt eine Entwicklung, die das ändern könnte: SAAS. Wenn Software nur
noch als Service im Netz bereit gestellt wird, muss der betreibende auf
einmal das Blech selber bezahlen. Und jetzt kann es ökonomisch sinnvoll
werden, auf den Ressourcenverbrauch der Software zu achten.

Ich fand die obige Regel schon immer falsch. Man sollte immer die
optimalen Datenstrukturen und Algorithmen verwenden, und nur wenn das
signifikanten Mehraufwand bedeutet, überlegen, ob es an der jeweiligen
Stelle auch lohnt. Aber dazu muss man halt auch erst mal verinnerlichen,
was Algorithmen und Datenstrukturen sind, und nicht nur Copy & Paste von
Stackoverflow beherrschen.


Marcel

[Gerrit Heitsch]

On 1/10/24 23:04, Arno Welzel wrote:
> Kay Martinen, 2024-01-10 18:10:
>
>> Am 10.01.24 um 17:31 schrieb Stefan Ram:
>>> Diedrich Ehlerding <diedrich....@t-online.de> writes:
>>>> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
>>>> Größenordnungen höher ist als damals für die ganze Uni reichte.
>>>
>>> Ja. Allerdings werden die Wachstumsraten, die man für einzelne
>>> Kerne hat, seit 2005 kaum noch größer. Herb Sutter schrieb
>>> etwas zu diesem Thema in Dr. Dobb's Journal, 30(3), March 2005.
>>>
>>> Wir kamen von dem 1-MHz-6502 zu Prozessoren mit 1 GHz, sagen wir um
>>> das Jahr 2000 herum. Solch eine Vertausendfachung der Taktfrequenz
>>> haben wir seitdem nicht einmal nährungsweise wieder erlebt.
>>
>> Jetzt fehlt doch noch eine Vertausendfachung des Durchsatzes beim
>> Nadelöhr Arbeitsspeicher. Oder; noch heftiger; beim Durchsatz zu
>> Massenspeichern.
>
> NVMe-SSDs sind schon bei mehr als 3 GB/s angekommen. Damit schreibt man
> 1 TB Daten in weniger als 10 Minuten voll.

Die schaffen das durchgehend? Auch wenn sie zwischendrin Blocks löschen
müssen?

Gerrit

[Gerrit Heitsch]

On 1/10/24 23:11, Andreas Kohlbach wrote:
>
> Um 2005 scheint mir auch das Ende der Fahnenstange erreicht gewesen zu
> sein, was die Leistung *einer* CPU anbetraf. Dann gab es eigentlich nur
> noch immer mehr Kerne in /einer/ CPU.

Ja, aber die Kerne wurden auch wieder schneller. Ich hab hier aktuell
einen Ryzen 5 5600X. Davor steckten in demselben Board ein Ryzen 5 1600
und ein Ryzen 5 3600. Es sind immer 6 Kerne (2 Threads pro Kern). Der
Rechner wurde mit jeder Aufrüstung merkbar schneller.

Gerrit

[Peter J. Holzer]

On 2024-01-11 06:50, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> Tabelle nach Chandler Carruth (2014):
>
> CPUS HAVE A HIERARCHICAL CACHE SYSTEM
>
> One cycle on a 3 GHz processor 1 ns
^^^^^ ^^^^^^
Hmm.

hp

[Peter J. Holzer]

On 2024-01-11 08:52, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>|eine RTX 4090 kostet ungefähr 2000 Mark – und gibt es von
>
> Oops, ja ... Ich habe ein Programm, welches alle Webseiten
> automatisch umschreibt, bevor ich sie sehe. Diese
> Programm ersetzt "Euro" durch "Mark"

Ich hoffe, dein Programm multipliziert auch alle Zahlen korrekt mit
1,95583 (und dividiert sie durch den VPI 2000).

hp

[Peter J. Holzer]

On 2024-01-11 07:55, Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
> On 1/10/24 23:11, Andreas Kohlbach wrote:
>> Um 2005 scheint mir auch das Ende der Fahnenstange erreicht gewesen zu
>> sein, was die Leistung *einer* CPU anbetraf. Dann gab es eigentlich nur
>> noch immer mehr Kerne in /einer/ CPU.
>
> Ja, aber die Kerne wurden auch wieder schneller.

Ja. Ich war überrascht um wieviel schneller mein aktueller Laptop (mit
"13th Gen Intel(R) Core(TM) i5-13600H") als mein 5 Jahre alter Desktop
(mit "Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz") ist. Die maximale
Taktfrequenz ist nur 26% höher (4.8 GHz statt 3.8 Ghz) aber bei vielen
Workloads ist er um 50% schneller, bei manchen sogar doppelt so schnell.
Gut, vielleicht ist auch das RAM schneller.

hp

[Michael van Elst]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:

>Die schaffen das durchgehend? Auch wenn sie zwischendrin Blocks lÃķschen
>mÞssen?

Jein. Es gibt/gab zumindest Modelle, die knapp 2GB durchgehend schreiben
konnten. Aber allgemein wird zur Kostensenkung ein schneller Cache
verwendet und wenn der voll ist, wird es langsamer. Bei schlechten
Exemplaren geht es auf 100MB/s runter nachdem ein paar zehn GB am
Stück geschrieben wurden.

Zweites Limit ist, gerade bei den ganz schnellen Exemplaren, die Temperatur.
Da wird dann ohne ausreichende Kühlung gedrosselt.

[Kay Martinen]

Am 11.01.24 um 09:52 schrieb Stefan Ram:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> |eine RTX 4090 kostet ungefähr 2000 Mark – und gibt es von
>
> Oops, ja ... Ich habe ein Programm, welches alle Webseiten
> automatisch umschreibt, bevor ich sie sehe. Diese

Greasemonkey? :)

[Dennis Grevenstein]

Peter J. Holzer <hjp-u...@hjp.at> wrote:
>
> Ja. Ich war überrascht um wieviel schneller mein aktueller Laptop (mit
> "13th Gen Intel(R) Core(TM) i5-13600H") als mein 5 Jahre alter Desktop
> (mit "Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz") ist. Die maximale
> Taktfrequenz ist nur 26% höher (4.8 GHz statt 3.8 Ghz) aber bei vielen
> Workloads ist er um 50% schneller, bei manchen sogar doppelt so schnell.
> Gut, vielleicht ist auch das RAM schneller.

vielleicht wirkt bei Euch ja auch noch so eine Konditionierung von
früher nach, wo alle gelernt haben, dass mehr MHz/GHz schneller ist.
Eine Zeit lang haben die Hersteller versucht, den CPUs eine Art
"Quantispeed" rating zu verpassen (AMD hatte das angefangen?) und
mittlerweile kapiert niemand mehr irgendwas. Oftmals zählt nur
noch so eine ganz einfach Heuristik "wenn die Zahl größer ist,
dann muss es besser sein", so wie Intel vor Jahrzehnten Werbung
mit 386er und 486er gemacht hat. Die Kunden scheinen intellektuell
überfordert. Apple hat die Zeichen erkannt und benennt CPUs noch
mit einfachen Zahlen und einem lächerlichen Zusatz Pro, Max, Ultra
wie in der Waschmittelwerbung.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."

[Michael Kraemer @ home]

Dennis Grevenstein wrote:

> vielleicht wirkt bei Euch ja auch noch so eine Konditionierung von
> früher nach, wo alle gelernt haben, dass mehr MHz/GHz schneller ist.
> Eine Zeit lang haben die Hersteller versucht, den CPUs eine Art
> "Quantispeed" rating zu verpassen (AMD hatte das angefangen?) und
> mittlerweile kapiert niemand mehr irgendwas.

Zumal "CPU" im Sinne eines monolithischen Etwas auch nicht mehr zutreffend ist,
bei den vielen Funktionseinheiten die eine heutige CPU hat.
IBM zB hat bei ihren neueren POWERs die "CPU-Zeit" neu und etwas eigenwillig
definiert.
Also nicht mehr nur die Zeit, die ein Progamm auf der CPU rechnet,
sondern auch den Nutzungsgrad der "CPU" reinmultipliziert.
Das macht benchmarking nicht grade einfacher.

[Michael Kraemer @ home]

Ich dachte da mehr an Anwendungen der Sorte Wettervorhersage fuer morgen.
Die sollte moeglichst innert 24h fertig sein.
Einen schnelleren Rechner laesst man dann halt genauer rechnen, aber immer noch
24h lang.
Ich glaube nicht, dass der Wetterdienst frueher Feierabend macht, wenn der
Rechner schneller ist.

[Peter J. Holzer]

On 2024-01-11 09:54, Dennis Grevenstein <dennis.gr...@gmail.com> wrote:
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> Ja. Ich war überrascht um wieviel schneller mein aktueller Laptop (mit
>> "13th Gen Intel(R) Core(TM) i5-13600H") als mein 5 Jahre alter Desktop
>> (mit "Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz") ist. Die maximale
>> Taktfrequenz ist nur 26% höher (4.8 GHz statt 3.8 Ghz) aber bei vielen
>> Workloads ist er um 50% schneller, bei manchen sogar doppelt so schnell.
>> Gut, vielleicht ist auch das RAM schneller.
>
> vielleicht wirkt bei Euch ja auch noch so eine Konditionierung von
> früher nach, wo alle gelernt haben, dass mehr MHz/GHz schneller ist.

Nein, mehr die Erfahrung der letzten 15 Jahre, dass der
Performance-Gewinn durch einen neuen Rechner eher bescheiden ist,
jedenfalls was die CPU anlangt. SSD statt HD hat viel gebracht. Stetig
wachsendes RAM war auch fein. Aber bei den CPUs hat sich wenig getan.
Insofern war ich skeptisch (und dann positiv überrascht) als als Ersatz
für 5 Jahre alte Desktops mit i7 neue Laptops mit i5 angekündigt waren.

hp

[Arno Welzel]

Stefan Möding, 2024-01-11 07:48:

> Arno Welzel <use...@arnowelzel.de> writes:
>
>> Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
>> Das ist keinesfalls immer gegeben.
>
> Da läuft die Anwendung ja auch nur mit 5 Demo-Datensätzen.

In meiner Welt nicht. Da gehört zur Abnahme der Software *zwingend* auch
ein Lasttest dazu.

[Arno Welzel]

Marcel Mueller, 2024-01-11 08:29:

[...]

> Aber die meisten Entwickler, die ich kenne (und das sind einige) achten
> überhaupt nicht darauf, welche Datenstrukturen sie verwenden, und es ist
> ihnen auch vollkommen egal, ob dabei in jedem Schleifendurchlauf nochmal
> der gesamte Arbeitsvorrat durchsucht wird, also quadratische
> Komplexität. Erst wenn eine Stelle wirklich ein Problem macht, wird
> optimiert.

Die würden bei mir rausfliegen. Ja, das meine ich ernst. Ja, ich kann
sowas entscheiden.

> Es gibt eine alte Entwickler-Regel: first make it work, then make it
> fast. Die produziert genau jene, verbreitete Software, die alle zum
> Entwicklungszeitpunkt verfügbaren Systemressourcen effizient verbraucht.

Diese Regel ist Schwachsinn. Genauso wie "never change a running
system", wenn es um Sicherheitsupdates geht.

> Und wenn man berücksichtigt, dass "make it fast" nicht selten bedeutet
> "wegschmeißen und neu machen", ist die vermeintliche Ersparnis durch
> diese Vorgehensweise auch gar nicht mehr so groß.

Genau deswegen macht man es auch nicht so.

> Das ist halt eine ökonomische Sache. Die Entwickler bezahlt der
> Softwarehersteller, das Blech (Rechner) bezahlt der Kunde, also
> Ressourcenverbrauch egal.

In meiner Welt nicht.

> Es gibt eine Entwicklung, die das ändern könnte: SAAS. Wenn Software nur
> noch als Service im Netz bereit gestellt wird, muss der betreibende auf
> einmal das Blech selber bezahlen. Und jetzt kann es ökonomisch sinnvoll
> werden, auf den Ressourcenverbrauch der Software zu achten.

Genau das passiert zunehmend.

[Arno Welzel]

Gerrit Heitsch, 2024-01-11 08:50:

> On 1/10/24 23:04, Arno Welzel wrote:
>> Kay Martinen, 2024-01-10 18:10:

[...]

>>> Jetzt fehlt doch noch eine Vertausendfachung des Durchsatzes beim
>>> Nadelöhr Arbeitsspeicher. Oder; noch heftiger; beim Durchsatz zu
>>> Massenspeichern.
>>
>> NVMe-SSDs sind schon bei mehr als 3 GB/s angekommen. Damit schreibt man
>> 1 TB Daten in weniger als 10 Minuten voll.
>
> Die schaffen das durchgehend? Auch wenn sie zwischendrin Blocks löschen
> müssen?

Wozu sollten sie Blocks löschen müssen, wenn sie noch leer sind ;-).

Im Ernst: ja, 3 GB/s wird nicht konstant durchgehalten, irgenwann geht
es dann auf unter 1 GB/s runter. Aber wenn ich hier testweise Daten von
einer NVMe-SSD auf die andere kopiere, geht es mit 2,8 GB/s los und da
bleibt dann recht lange so, bis es dann auf etwa 800-900 MB/s landet.

[Arno Welzel]

Andreas Kohlbach, 2024-01-10 23:11:

> On 10 Jan 2024 16:31:13 GMT, Stefan Ram wrote:

[...]

>> Wir kamen von dem 1-MHz-6502 zu Prozessoren mit 1 GHz, sagen wir um
>> das Jahr 2000 herum. Solch eine Vertausendfachung der Taktfrequenz
>> haben wir seitdem nicht einmal nährungsweise wieder erlebt.
>
> Da erinnere ich mich an die späten 90er, als Hobbyisten mit
> Flüssigkeits-Kühlung versuchten, eine XXX MHz mit 1 GHz zu takten. Und
> die Bilder dazu. Die zeigten einen Computer mit vielen Schläuchen, als ob
> er an ein Lebenserhaltungssystem einer Notaufnahme angeschlossen war.

Das ist heute immer noch so. Flüssigkühlung gehört bei anspruchsvolleren
"Gamer"-PCs zum Standard:

<https://www.caseking.de/king-mod-systems-gaming-pc-red-nebula-amd-ryzen-7-7800x3d-4070-ti-custom-wakue-sipc-638.html>

> Um 2005 scheint mir auch das Ende der Fahnenstange erreicht gewesen zu
> sein, was die Leistung *einer* CPU anbetraf. Dann gab es eigentlich nur
> noch immer mehr Kerne in /einer/ CPU. Auch wenn Betriebssysteme jeden Kern
> als eigene CPU listen.

Ja, das ist ja auch sinnvoll. Software profitiert davon, Dinge
*parallel* ausführen zu können.

[Arno Welzel]

Stefan Ram, 2024-01-11 09:30:

[...]
> Web 2023:
>
> |Ich brauche eine mit Nvidia RTX 4090 GPU. Die 4090 muß es
> |nämlich sein, weil ich für KI-Zeug vor allem viel
> |Videospeicher brauche, und nur die 4090 hat 24 Gibioktett.
> ...

> |eine RTX 4090 kostet ungefähr 2000 Mark – und gibt es von

> |unterschiedlichen Herstellern, die da alle ihre eigene
> |Kühlung und so weiter draufknallen

Was soll "Mark" sein? 4090 kostet um die 2000 EUR, nicht "Mark".

[Arno Welzel]

Peter J. Holzer, 2024-01-11 15:04:

[...]

> Nein, mehr die Erfahrung der letzten 15 Jahre, dass der
> Performance-Gewinn durch einen neuen Rechner eher bescheiden ist,
> jedenfalls was die CPU anlangt. SSD statt HD hat viel gebracht. Stetig
> wachsendes RAM war auch fein. Aber bei den CPUs hat sich wenig getan.

Man muss nur lange genug warten ;-)

Als ich vor einiger Zeit einen Xeon E5-1650 v2 mit DDR3-RAM samt
Mainboard durch einen AMD FX5800X mit DDR4-RAM ersetzt habe, war der
Unterschied *sehr* deutlich - etwa Faktor 2-3 schneller.

[Kay Martinen]

Am 11.01.24 um 08:29 schrieb Marcel Mueller:

> Am 10.01.24 um 22:57 schrieb Arno Welzel:
>> Marcel Mueller, 2024-01-10 18:43:
>>> Nach meinen Erfahrungen wird Software immer so programmiert, dass sie
>>> den gut ausgestatteten Rechner des Entwicklers nicht völlig lahm legt.
>>> Auf dem Rechner der User funktioniert das nur deswegen einigermaßen gut,
>>> weil der zwei Jahre später, wenn er das Produkt auf seiner Kiste hat,
>>> mindestens gleichschnell ist.

Noch'n Schweinezyklus?

>> Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
>> Das ist keinesfalls immer gegeben.

Dann könnte man Gute und Schlechte Entwickler unterscheiden - wenn man
wüsste welche HW sie im Einsatz hatten bei $Produkt_X??? ;-)

Wenn $Produkt_X auf Kundenhardware schnell genug läuft UND

War die "Erst"-HW älter muß er ja gut sein.
War die "Erst"-HW neuer muß er schlecht sein.

Wenn es so einfach wäre.... Toll oder? ;)

> Der Entwickler hat nicht die neueste, aber zum Kaufzeitpunkt gut
> ausgestattete Hardware, denn die Entwickertools sind wahrlich keine
> Kostverächter.

Und immer dieser Kostendruck sich wegen neuerer Tools immer neue HW
anschaffen zu müssen - oder?

> Aber die meisten Entwickler, die ich kenne (und das sind einige) achten
> überhaupt nicht darauf, welche Datenstrukturen sie verwenden, und es ist
> ihnen auch vollkommen egal, ob dabei in jedem Schleifendurchlauf nochmal
> der gesamte Arbeitsvorrat durchsucht wird, also quadratische
> Komplexität. Erst wenn eine Stelle wirklich ein Problem macht, wird
> optimiert.
>
> Es gibt eine alte Entwickler-Regel: first make it work, then make it
> fast. Die produziert genau jene, verbreitete Software, die alle zum
> Entwicklungszeitpunkt verfügbaren Systemressourcen effizient verbraucht.
> Und wenn man berücksichtigt, dass "make it fast" nicht selten bedeutet
> "wegschmeißen und neu machen", ist die vermeintliche Ersparnis durch
> diese Vorgehensweise auch gar nicht mehr so groß.
>
> Das ist halt eine ökonomische Sache. Die Entwickler bezahlt der
> Softwarehersteller, das Blech (Rechner) bezahlt der Kunde, also
> Ressourcenverbrauch egal.
>
> Es gibt eine Entwicklung, die das ändern könnte: SAAS. Wenn Software nur
> noch als Service im Netz bereit gestellt wird, muss der betreibende auf
> einmal das Blech selber bezahlen. Und jetzt kann es ökonomisch sinnvoll
> werden, auf den Ressourcenverbrauch der Software zu achten.

Das damit einhergehende "SW gehört nicht dir, du kannst sie nur Leasen"
Plus Online-Zwang finde ich dabei am (ver)störendsten.

> Ich fand die obige Regel schon immer falsch. Man sollte immer die
> optimalen Datenstrukturen und Algorithmen verwenden, und nur wenn das
> signifikanten Mehraufwand bedeutet, überlegen, ob es an der jeweiligen
> Stelle auch lohnt. Aber dazu muss man halt auch erst mal verinnerlichen,
> was Algorithmen und Datenstrukturen sind, und nicht nur Copy & Paste von
> Stackoverflow beherrschen.

Und mir fällt hierbei auf das immer (nur) noch von "Entwicklern" die
Rede ist, und nicht mehr von Programmierern.

Liegt das NUR daran das es oft "Developer" heißt und übersetzt wird,
oder sind die echten Programmierer ausgestorben? Vielleicht weil sie für
X Zeilen Code länger brauchten als $Timeslot befielt - und die Qualität
der Arbeit sowieso niemand mehr nach mißt (nicht kann oder will)?

[Kay Martinen]

Am 11.01.24 um 11:44 schrieb Michael Kraemer @ home:

Bei solchen Anwendungen ist es sicher vernünftig einen Gewissen
Zeitrahmen ein halten zu können. Ich vermute da werden die Aktuellen
Modelle genommen und was sie an zeit und daten brauchen und dann
extrapoliert ob man mit "Schweineteurer_SuperHardware X" schneller
fertig würde. Und ob man dies Schneller Fertig in eine Signifikante
Verbesserung des Modells umwandeln kann. Und dann wird eben die HW
bestellt und muß eine Zeit Y durchhalten in der es wohl nur kleine
Optimierungen geben wird.

Kurz: Am Ende hat man sauviel geld ausgegeben und wird immer noch genau
gleich schnell fertig aber das Ergebnis ist genauer als vorher.

IMHO hat man früher mit einem Gröberen Raster an Datenpunkten modelliert
als heute. Weil es zu Zeit X mit HW Y und Software Z halt nicht genauer
ging. Heute kommt dann halt noch Unfähigkeit und entstehender BLOAT dazu. ;)

In Prä-IT zeiten wußten die Leute im Grunde nur das es abends dunkel
wird. Alles andere war schon Luxus. Heute ist dagegen doch
Schlaraffenland (abgebrannt).

[Kay Martinen]

Am 11.01.24 um 18:14 schrieb Arno Welzel:

> Stefan Möding, 2024-01-11 07:48:
>
>> Arno Welzel <use...@arnowelzel.de> writes:
>>
>>> Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
>>> Das ist keinesfalls immer gegeben.
>>
>> Da läuft die Anwendung ja auch nur mit 5 Demo-Datensätzen.
>
> In meiner Welt nicht. Da gehört zur Abnahme der Software *zwingend* auch
> ein Lasttest dazu.
>

Mit 100% Last auf jedem Kern bis die Hardware kocht?

Ein Echter Test muß doch bis an die Schmerzgrenze gehen sonst macht's
keinen Sinn. ;-)

Erinnere mich dunkel an (SATA) Chips die bei zu viel Temperatur Fehler
machten und das Dateisystem korrumpierten...

[Gerrit Heitsch]

Intel hatte mal welche bei denen die SATA-Ports nach ein paar Monaten
ausfallen konnten:

https://www.anandtech.com/show/4142/intel-discovers-bug-in-6series-chipset-begins-recall

Später dann auch noch einen Fehler in der C2000-Serie der Atom-CPUs:

https://www.theregister.com/2017/02/06/cisco_intel_decline_to_link_product_warning_to_faulty_chip/

Den konnte man aber selber fixen wenn man löten kann:

https://schultschik.de/technik/synology-ds415-intel-c2000-bug-reparatur



Gerrit

[Marcel Mueller]

Am 11.01.24 um 18:23 schrieb Kay Martinen:

>> Der Entwickler hat nicht die neueste, aber zum Kaufzeitpunkt gut
>> ausgestattete Hardware, denn die Entwickertools sind wahrlich keine
>> Kostverächter.
>
> Und immer dieser Kostendruck sich wegen neuerer Tools immer neue HW
> anschaffen zu müssen - oder?

Das ist nicht primär treibend. Der Wechsel auf Win11 hat ähnlich viel
zusätzlich verbraucht, wie 2 Major Updates der Entwickertools.
Die üblichen ca. 5 Jahre Nutzungsdauer bekommt man schon hin.

>> Es gibt eine Entwicklung, die das ändern könnte: SAAS. Wenn Software nur
>> noch als Service im Netz bereit gestellt wird, muss der betreibende auf
>> einmal das Blech selber bezahlen. Und jetzt kann es ökonomisch sinnvoll
>> werden, auf den Ressourcenverbrauch der Software zu achten.
>
> Das damit einhergehende "SW gehört nicht dir, du kannst sie nur Leasen"
> Plus Online-Zwang finde ich dabei am (ver)störendsten.

Das stört halt immer weniger Leute. Es gibt ja auch Vorteile.
Ich bin auch kein Freund davon, da es die Kosten mittelfristig hoch
treibt und häufig zu Kompatibilitätsproblemen kommt.

> Und mir fällt hierbei auf das immer (nur) noch von "Entwicklern" die
> Rede ist, und nicht mehr von Programmierern.
>
> Liegt das NUR daran das es oft "Developer" heißt und übersetzt wird,

Keine Ahnung. Das ist für mich synonym.


Marcel

[Gerald E¡scher]

Dennis Grevenstein schrieb am 11/1/2024 10:54:

> vielleicht wirkt bei Euch ja auch noch so eine Konditionierung von
> früher nach, wo alle gelernt haben, dass mehr MHz/GHz schneller ist.

Ich nicht. Ich habe Anfang der 90er gelernt, dass bei gleicher
Taktfrequenz ein i486 etwa doppelt so schnell ist wie ein i386. Damals
hat sich noch kein DAU für Taktfrequenzen interessiert.

> Eine Zeit lang haben die Hersteller versucht, den CPUs eine Art
> "Quantispeed" rating zu verpassen (AMD hatte das angefangen?)

Davor gab es das "P-Rating". https://de.wikipedia.org/wiki/P-Rating

--
Gerald

[Kay Martinen]

Am 11.01.24 um 19:28 schrieb Marcel Mueller:

> Am 11.01.24 um 18:23 schrieb Kay Martinen:

>> Und mir fällt hierbei auf das immer (nur) noch von "Entwicklern" die
>> Rede ist, und nicht mehr von Programmierern.
>>
>> Liegt das NUR daran das es oft "Developer" heißt und übersetzt wird,
>
> Keine Ahnung. Das ist für mich synonym.

Wenn ich drüber nachdenke ist ein Entwickler aus meiner; eher externen;
Sicht viel mehr so was wie der Oberarchitekt eines Projektes. Also der,
der die Richtung vorgibt, die Teile organisiert, der einen Plan hat
(hoffentlich). Und vielleicht nicht mal selbst programmiert - oder es
könnte. Und Programmierer sind dann diejenigen die das was "entwickelt"
wurde umsetzen - müssen - in Code.

Das mag Theoretisch, Verkopft und Dysfunktional anmuten aber, mal
Ehrlich: In den Letzten Jahren habe ich den Eindruck das es zutreffen
könnte bei all den Fehlern die grade noch so entdeckt werden,
vermeidbaren Fehlentwicklungen und Bugs über die <irgendwer> gestolpert
ist - nur nicht der Hersteller. Okay, das ist nur die Halbe Wahrheit
denn es kommt ja noch mehr dazu.

Aber da denke ich unwillkürlich an den einen Specht der die Zivilisation
zerhacken könnte - wenn Häuser so gebaut würden wie Programme. :)

[Andreas Kohlbach]

On Thu, 11 Jan 2024 09:54:32 -0000 (UTC), Dennis Grevenstein wrote:
>
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>
>> Ja. Ich war überrascht um wieviel schneller mein aktueller Laptop (mit
>> "13th Gen Intel(R) Core(TM) i5-13600H") als mein 5 Jahre alter Desktop
>> (mit "Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz") ist. Die maximale
>> Taktfrequenz ist nur 26% höher (4.8 GHz statt 3.8 Ghz) aber bei vielen
>> Workloads ist er um 50% schneller, bei manchen sogar doppelt so schnell.
>> Gut, vielleicht ist auch das RAM schneller.
>
> vielleicht wirkt bei Euch ja auch noch so eine Konditionierung von
> früher nach, wo alle gelernt haben, dass mehr MHz/GHz schneller ist.

64 Bit ist schneller als 32. ;-)

Diese Linux-Installation (nun im dritten Host) muss ich um 2010
aufgesetzt haben. Damals gab es schon 64 Bit CPUs in Desktops und
Laptops. Ein Bekannter meinte auch, er müsse unbedingt Windows 7 64 Bit
installieren.

Es gab sogar Werbung, die die Vorteile seines Produktes allein an der
Tatsache festmachte, eine CPU mit der doppelten "Bitzahl" seiner
Konkurrenten zu haben.

Ich war der Meinung, dass sie 32 zu 64 nichts nimmt. Die Sache vielleicht
gar langsamer macht. Vielleicht hatte ich aus diesem Grund für Linux
32 Bit (PAE) gewählt, was ich heute noch mit mir rum schleppe.

PS: Auf dem neueren Rechner läuft 64 Bit Debian. Der scheint im
Lichtjahre schneller als der 32 Bitter zu sein, was aber an seiner
wesentlich besseren Ausstattung liegt.

PS2: Ich will 8 Bit zurück! War doch die beste Zeit. :-)
--
Andreas

[Markus Elsken]

Moin!

Am 11.01.24 um 18:34 schrieb Kay Martinen:

> Mit 100% Last auf jedem Kern bis die Hardware kocht?

Volle Last ja, aber kochen darf da nichts. Da müssen selbst bei 100%
noch Reserven sein. Nicht unüblich, dass so ein Server die nächsten
Jahre bei maximaler Last verbringt, das muss er ohne Zucken aushalten.

mfg Markus

[Günter Frenz]

Am Thu, 11 Jan 2024 21:17:38 +0100 schrieb Kay Martinen:

> Am 11.01.24 um 19:28 schrieb Marcel Mueller:
> > Am 11.01.24 um 18:23 schrieb Kay Martinen:
>
> >> Und mir fällt hierbei auf das immer (nur) noch von "Entwicklern"
> >> die Rede ist, und nicht mehr von Programmierern.
> >>
> >> Liegt das NUR daran das es oft "Developer" heißt und übersetzt
> >> wird,
> >
> > Keine Ahnung. Das ist für mich synonym.
>
> Wenn ich drüber nachdenke ist ein Entwickler aus meiner; eher
> externen; Sicht viel mehr so was wie der Oberarchitekt eines
> Projektes. Also der, der die Richtung vorgibt, die Teile organisiert,
> der einen Plan hat (hoffentlich). Und vielleicht nicht mal selbst
> programmiert - oder es könnte. Und Programmierer sind dann diejenigen
> die das was "entwickelt" wurde umsetzen - müssen - in Code.

Die letzteren sind nach der Berufsausbildung meist Fachinformatiker der
Fachrichtung Anwendungs_entwicklung_. Die Fachinformatiker gibt es
außerdem noch in den Geschmacksrichtungen Systemintegration, Daten- und
Prozessanalyse und Digitale Vernetzung. Die letzten beiden erst seit
2020, die anderen beiden schon seit 1997.

Bis denn
Günter

[Marcel Mueller]

Am 11.01.24 um 21:17 schrieb Kay Martinen:

> Am 11.01.24 um 19:28 schrieb Marcel Mueller:
>> Am 11.01.24 um 18:23 schrieb Kay Martinen:
>
>>> Und mir fällt hierbei auf das immer (nur) noch von "Entwicklern" die
>>> Rede ist, und nicht mehr von Programmierern.
>>>
>>> Liegt das NUR daran das es oft "Developer" heißt und übersetzt wird,
>>
>> Keine Ahnung. Das ist für mich synonym.
>
> Wenn ich drüber nachdenke ist ein Entwickler aus meiner; eher externen;
> Sicht viel mehr so was wie der Oberarchitekt eines Projektes. Also der,
> der die Richtung vorgibt, die Teile organisiert, der einen Plan hat
> (hoffentlich). Und vielleicht nicht mal selbst programmiert - oder es
> könnte. Und Programmierer sind dann diejenigen die das was "entwickelt"
> wurde umsetzen - müssen - in Code.

Diese Nomenklatur ist in der Branche nicht üblich. Was Du beschreibst
wäre ein Software-Architekt. Entwickler sind die Exekutiven.
Programmierer sagt heute keiner mehr. Suche mal nach einer
Stellenausschreibung für Programmierer. Aber die Tätigkeit heißt z.T.
immer noch Programmieren.

> Das mag Theoretisch, Verkopft und Dysfunktional anmuten aber, mal
> Ehrlich: In den Letzten Jahren habe ich den Eindruck das es zutreffen
> könnte bei all den Fehlern die grade noch so entdeckt werden,
> vermeidbaren Fehlentwicklungen und Bugs über die <irgendwer> gestolpert
> ist - nur nicht der Hersteller. Okay, das ist nur die Halbe Wahrheit
> denn es kommt ja noch mehr dazu.

Bugs und Sicherheitslücken gibt und gab es immer. Der höhere
Vernetzungsgrad macht es nur einfacher, sie aus sicherer Entfernung und
massenhaft auszunutzen. Heißt, die Anforderungen sind stark gestiegen.

Hier ging es aber eher um die Rechenleistung früher und heute. Und da
musste man sich vor 40 Jahren halt wesentlich mehr Mühe geben. Es ist
also mehr Aufwand in die Programme geflossen. Das lohnt heute kaum noch,
denn eine Regel lautet: "Blech ist immer billiger als Menschen."
Das liegt natürlich zum guten Teil daran, dass sich unsere Haushalte für
Staat und Infrastruktur zum erheblichen Teil aus Lohnnebenkosten
finanzieren und für die Technik zumeist keine Steuern anfallen.

> Aber da denke ich unwillkürlich an den einen Specht der die Zivilisation
> zerhacken könnte - wenn Häuser so gebaut würden wie Programme. :)

Werden sie zum Teil. Siehe Erbeben in der Türkei oder das Kaufhaus in
Asien, das damals zusammengeklappt ist.

Der Vergleich müsste aber eher dahin gehen, dass die Häuser aufgrund von
Veränderungen heute häufig Unwettern und Erdbeben hoher Stärke
ausgesetzt sind, und deshalb robuster ausfallen müssen.

Habe neulich ein Haus mit Panzerglas im EG gesehen. War schon irgendwie
surreal, wenn man aus dem Fenster in ein "Aquarium" mit Dreckwasser blickt.


Marcel

[p...@pocnet.net]

Kay Martinen <use...@martinen.de> wrote:

> Das damit einhergehende "SW gehört nicht dir, du kannst sie nur Leasen"

Software "gehört" einem schon seit langem nicht (mehr). Man erwarb "früher"
ein Nutzungsrecht durch Einmalzahlung. Heute lässt man sich den Schweinezyklus
"Bug gefunden, gefixt, dafür zwei neue eingebaut" durch zyklische Bezahlung
versüßen.

> Und mir fällt hierbei auf das immer (nur) noch von "Entwicklern" die
> Rede ist, und nicht mehr von Programmierern.
>
> Liegt das NUR daran das es oft "Developer" heißt und übersetzt wird,

Vermutlich.

> oder sind die echten Programmierer ausgestorben?

Du meinst jene die nicht in Pascal programmieren? ;-)

--

:wq! PoC

[Stefan Möding]

p...@pocnet.net writes:

> Software "gehört" einem schon seit langem nicht (mehr). Man erwarb "früher"
> ein Nutzungsrecht durch Einmalzahlung. Heute lässt man sich den Schweinezyklus
> "Bug gefunden, gefixt, dafür zwei neue eingebaut" durch zyklische Bezahlung
> versüßen.

Das Nutzungsrecht war aber meist unbegrenzt und solange man die Hardware
hatte, konnte man die Software auch nutzen. Auch nachdem der Lieferant
lange von der Bildfläche verschwunden war.

Das Streaming von Musik und Filmen ist ja das gleiche Thema. Ich behalte
meine CDs/DVDs daher als Backup.

--
Stefan

[p...@pocnet.net]

Stefan Möding <Jan2024....@spamgourmet.com> wrote:

>> Software "gehört" einem schon seit langem nicht (mehr). Man erwarb "früher"
>> ein Nutzungsrecht durch Einmalzahlung. Heute lässt man sich den Schweinezyklus
>> "Bug gefunden, gefixt, dafür zwei neue eingebaut" durch zyklische Bezahlung
>> versüßen.
>
> Das Nutzungsrecht war aber meist unbegrenzt und solange man die Hardware
> hatte, konnte man die Software auch nutzen.

Ja, das stimmt.

> Auch nachdem der Lieferant lange von der Bildfläche verschwunden war.

Die heutzutage selbstverständliche Always-On-Verfügberkeit der
Internetanbindung durch DSL hat nicht nur Vorteile.

> Das Streaming von Musik und Filmen ist ja das gleiche Thema. Ich behalte
> meine CDs/DVDs daher als Backup.

Auch optische Medien altern und zeigen Lesefehler, btdt. Nicht nur die
gebrannten, auch die gekauften. Wobei die gekauften zwar erheblich länger
halten, aber nicht so lange wie Schallplatten. :-)

--

:wq! PoC

[Dennis Grevenstein]

p...@pocnet.net wrote:
>
> Auch optische Medien altern und zeigen Lesefehler, btdt. Nicht nur die
> gebrannten, auch die gekauften. Wobei die gekauften zwar erheblich länger
> halten, aber nicht so lange wie Schallplatten. :-)

Da hast Du sicher nicht unrecht, aber das Problem ist grundsätzlich
altbekannt. Wenn Archäolgen irgendwo jahrtausende alte Steintafeln
ausgraben, dann sind die in der Regel auch nicht mehr so lesbar
wie am ersten Tag.
Ich frage mich mittlerweile auch, ob nicht das Festhalten an alten
Medien ebenso ein Problem sein könnte und man vielleicht im Interesse
der Haltbarkeit ein dislokales backup auf einem anderen Datenträger
in einem Format braucht, das sich problemlos hin- und herkopieren
lässt. Ich persönlich habe z.B. keine LPs mehr, keine MCs, nur
wenige CDs. Mir ist mal meine damalige Lieblings-CD mitsamt dem
Autoradio gestohlen worden... Aber mp3s sind mir in 25 Jahren
noch keine verloren gegangen.

[Diedrich Ehlerding]

Arno Welzel meinte:

> Das ist heute immer noch so. Flüssigkühlung gehört bei
> anspruchsvolleren "Gamer"-PCs zum Standard:

Ich warte noch darauf, dass die Gamer zur Kühling mit flüssigem
Stickstoff greifen. So wie anno dunnemals die Eta10
<https://en.wikipedia.org/wiki/ETA10>
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Kay Martinen]

Am 12.01.24 um 20:51 schrieb Diedrich Ehlerding:

> Arno Welzel meinte:
>
>> Das ist heute immer noch so. Flüssigkühlung gehört bei
>> anspruchsvolleren "Gamer"-PCs zum Standard:

Denn den PC in einen Kühlschrank stellen reicht nicht. ;)

> Ich warte noch darauf, dass die Gamer zur Kühling mit flüssigem
> Stickstoff greifen.

Das stelle ich mir anspruchsvoll vor. Ob eine Unterkühlte heutige CPU da
überhaupt noch anläuft - oder gleich zerspringt. Frostschaden. ;-)

> So wie anno dunnemals die Eta10
> <https://en.wikipedia.org/wiki/ETA10>

Beim überfliegen fiel mir nix auf ob es da Probleme gäbe.

Ich denke heutige CPU's haben viel kleinere Strukturbreiten und müssen
m.E. erst mal ein bißchen warm (plusgrade) werden bevor man sie "runter
kühlt. Die Damalige Technik ist vermutlich eher für einen KALT-Start
geeignet gewesen. CMOS-Gatter auf Platine zusammen geschaltet = CPU wird
ja heute nicht mehr benutzt.

[p...@pocnet.net]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:

> Ich frage mich mittlerweile auch, ob nicht das Festhalten an alten Medien
> ebenso ein Problem sein könnte

Das ist so, aber nur die halbe Antwort auf die Gesamtfragestellung.

> und man vielleicht im Interesse der Haltbarkeit ein dislokales backup auf
> einem anderen Datenträger in einem Format braucht, das sich problemlos hin-
> und herkopieren lässt.

Nur so lässt sich das Problem mildern.

Die Fragestellung inwieweit sich mehr oder weniger einst weit verbreitete aber
doch proprietäre Formate in einer wie auch immer gearteten Zukunft noch
verwerten lassen steht auf einem anderen Blatt.

--

:wq! PoC

[Raimund Huemmer]

Dennis Grevenstein <dennis.gr...@gmail.com> writes:

> Ich frage mich mittlerweile auch, ob nicht das Festhalten an alten
> Medien ebenso ein Problem sein könnte und man vielleicht im Interesse
> der Haltbarkeit ein dislokales backup auf einem anderen Datenträger
> in einem Format braucht, das sich problemlos hin- und herkopieren
> lässt.

Und dann bräuchte es noch ein Verfahren um deterministisch zu bestimmen,
wie lange

> Ich persönlich habe z.B. keine LPs mehr, keine MCs, nur
> wenige CDs. Mir ist mal meine damalige Lieblings-CD mitsamt dem
> Autoradio gestohlen worden... Aber mp3s sind mir in 25 Jahren
> noch keine verloren gegangen.
>
> gruss,
> Dennis

--

Life's too short to read boring signatures

[Raimund Huemmer]

Dennis Grevenstein <dennis.gr...@gmail.com> writes:

> Ich frage mich mittlerweile auch, ob nicht das Festhalten an alten
> Medien ebenso ein Problem sein könnte und man vielleicht im Interesse
> der Haltbarkeit ein dislokales backup auf einem anderen Datenträger
> in einem Format braucht, das sich problemlos hin- und herkopieren
> lässt.

Und dann bräuchte es noch ein Verfahren um deterministisch zu bestimmen,

wie lange die Daten noch halten ... ;-)

> Aber mp3s sind mir in 25 Jahren
> noch keine verloren gegangen.

Hier auch. Erstaunlich, dass nun schon wieder 25 Jahre vergangen sind
mit mp3 Musik.

Gruß
Raimund

[Michael Kraemer @ home]

Dennis Grevenstein wrote:

> Ich persönlich habe z.B. keine LPs mehr, keine MCs, nur
> wenige CDs. Mir ist mal meine damalige Lieblings-CD mitsamt dem
> Autoradio gestohlen worden... Aber mp3s sind mir in 25 Jahren
> noch keine verloren gegangen.

Das verschiebt das Problem aber nur,
denn auch die mp3's residieren auf einem $MEDIUM.
Und man braucht ein $PROGAMM um sie auf einem $GERAET hoerbar abspielen zu koennen.
Eine bis ans Lebensende $SORGLOSLOESUNG gibt es bisher mE nicht.

[Dennis Grevenstein]

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>
> Das verschiebt das Problem aber nur,
> denn auch die mp3's residieren auf einem $MEDIUM.
> Und man braucht ein $PROGAMM um sie auf einem $GERAET hoerbar abspielen zu koennen.
> Eine bis ans Lebensende $SORGLOSLOESUNG gibt es bisher mE nicht.

Eben deshalb die notwendige Möglichkeit zum umkopieren und konvertieren.
Ewig sorglos ist man damit natürlich nicht, aber in meiner persönlichen
Erfahrung hat sich so ein lächerliches Format wie mp3 als sehr langlebig
erwiesen. Nichtmal Apple würde sich trauen, "aus Sicherheitsgründen"
morgen kein mp3 mehr zu unterstützen.

[Stefan Möding]

Raimund Huemmer <r...@rayjoe.de> writes:

> Hier auch. Erstaunlich, dass nun schon wieder 25 Jahre vergangen sind
> mit mp3 Musik.

Womit man erwarten kann, dass mp3 auch noch etliche Jahre unterstützt
wird. Zumindest so lange, bis es mir dann auch egal ist...

Lokale Datensicherung ist ein lösbares Problem, womit die eigene mp3
Sammlung die sicherste Form sein dürfte, um seine Lieblingsmusik noch
etliche Jahre hören zu können. Jedenfalls erscheint es mir sinnvoller,
als ein Streaming-Abo, wo ich keinerlei Kontrolle über das Angebot habe.

--
Stefan

[Dennis Grevenstein]

Stefan Möding <Jan2024....@spamgourmet.com> wrote:
>
> Lokale Datensicherung ist ein lösbares Problem, womit die eigene mp3
> Sammlung die sicherste Form sein dürfte, um seine Lieblingsmusik noch
> etliche Jahre hören zu können. Jedenfalls erscheint es mir sinnvoller,
> als ein Streaming-Abo, wo ich keinerlei Kontrolle über das Angebot habe.

Das sind ja tatsächlich 2 verschiedene Dinge. Zum einen das Problem,
dass die Musik zu spielen aufhört, wenn ich nicht mehr jeden Monat
bezahle. Und zusätzlich das Problem des Angebots. Es gibt keine
Garantie, dass mein Lieblings-content nicht irgendwann mal verändert,
aus dem Angebot gelöscht oder an moderne Sensibilitäten angepasst
wird. Darauf aufbauend dann das Problem des Zugangs, falls der
Anbieter morgen entscheidet, nur noch bestimmte Systeme zu unterstützen
oder eine neue Form von DRM verlangt. Dann könnte man auf einmal
draußen bleiben müssen.

[Joerg Walther]

Stefan Möding wrote:

>Lokale Datensicherung ist ein lösbares Problem, womit die eigene mp3
>Sammlung die sicherste Form sein dürfte, um seine Lieblingsmusik noch
>etliche Jahre hören zu können.

Oder flac, das ist sogar Open Source.

>Jedenfalls erscheint es mir sinnvollßer,

>als ein Streaming-Abo, wo ich keinerlei Kontrolle über das Angebot habe.

Ack. Ich sag nur Amazon und Orwell 1984. Das ist zwar ein Buch, aber das
Problem ist das gleiche.

-jw-

--

And now for something completely different...

[Joerg Walther]

Michael Kraemer @ home wrote:

>Das verschiebt das Problem aber nur,
>denn auch die mp3's residieren auf einem $MEDIUM.
>Und man braucht ein $PROGAMM um sie auf einem $GERAET hoerbar abspielen zu koennen.
>Eine bis ans Lebensende $SORGLOSLOESUNG gibt es bisher mE nicht.

Nö, aber alle paar Jahre umkopieren auf $NEUESMEDIUM wird mit jeder
Mediengeneration eigentlich immer einfacher.
Hier: Von CD/DVD auf 2 TB HDDs, nervig, viele Medien einlegen; jetzt:
alles auf eine 18 TB HDD (natürlich mit Zwilling), also muss ich in
Zukunft nur eine HDD auf eine neue kopieren, das braucht dann
wahrscheinlich zwei Tage, aber ich muss ja nicht danebensitzen dabei.

[Marcel Mueller]

Am 10.01.24 um 23:11 schrieb Andreas Kohlbach:
> Und einen "Apollo-Computer" hat man seit Jahrzehnten in seiner
> Hosentasche.

Meinst Du HP-Apollo, also für die ganz großen Hosentaschen?


> Da erinnere ich mich an die späten 90er, als Hobbyisten mit
> Flüssigkeits-Kühlung versuchten, eine XXX MHz mit 1 GHz zu takten. Und
> die Bilder dazu. Die zeigten einen Computer mit vielen Schläuchen, als ob
> er an ein Lebenserhaltungssystem einer Notaufnahme angeschlossen war.

Das kam der Sache doch auch ziemlich nahe. ;-)


> Um 2005 scheint mir auch das Ende der Fahnenstange erreicht gewesen zu
> sein, was die Leistung *einer* CPU anbetraf. Dann gab es eigentlich nur
> noch immer mehr Kerne in /einer/ CPU. Auch wenn Betriebssysteme jeden Kern
> als eigene CPU listen.

IPC hat sich schon noch signifikant verbessert. Nur beim Takt ging es
seither deutlich langsamer.


Marcel

[Kay Martinen]

Am 13.01.24 um 15:16 schrieb Marcel Mueller:

> Am 10.01.24 um 23:11 schrieb Andreas Kohlbach:
>> Und einen "Apollo-Computer" hat man seit Jahrzehnten in seiner
>> Hosentasche.
>
> Meinst Du HP-Apollo, also für die ganz großen Hosentaschen?

Ich fürchte er meine den Apollo Guidance Computer (AGC). Das große mit
dem fädelkernspeicher und der "Fernbedienung" (DSKY?). :)

>> Da erinnere ich mich an die späten 90er, als Hobbyisten mit
>> Flüssigkeits-Kühlung versuchten, eine XXX MHz mit 1 GHz zu takten. Und
>> die Bilder dazu. Die zeigten einen Computer mit vielen Schläuchen, als ob
>> er an ein Lebenserhaltungssystem einer Notaufnahme angeschlossen war.
>
> Das kam der Sache doch auch ziemlich nahe. ;-)

Weiß nicht warum aber ich mußte hier an den Buckaroo Banzai Film (mit
Peter Weller) denken wo der US-Präsi ähnlich verkabelt wg. angeblicher
Alien-Aggressoren einen Umschlag öffnet. Heraus fiel die

"Declaration of War - Short Form" :-)

Ok, ich schweife ab, mit CPU hat das nur in so fern zu tun das es auch
einen Kampf gibt - um Moores Law - und ob es noch stimmt oder nicht.

>> Um 2005 scheint mir auch das Ende der Fahnenstange erreicht gewesen zu
>> sein, was die Leistung *einer* CPU anbetraf. Dann gab es eigentlich nur
>> noch immer mehr Kerne in /einer/ CPU. Auch wenn Betriebssysteme jeden Kern
>> als eigene CPU listen.
>
> IPC hat sich schon noch signifikant verbessert. Nur beim Takt ging es
> seither deutlich langsamer.

Quasi seitwärts. Bei gleichem Takt mehr nebenbei erledigen... 100 Kerne
sind ja keine Seltenheit mehr. Nicht mainstream aber auch nicht
exotisch. Welche Alte Anlage hatte so viele Rechenkerne und ab wann?

[Diedrich Ehlerding]

Michael Kraemer meinte:

>> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
>> Größenordnungen höher ist als damals für die ganze Uni reichte. Die
>> Briefe, die man heute auf dem Computer schreibt, werden aber nicht
>> schneller fertig als damals an der Schreibmaschine - sie werden nur
>> bunter und schöner.
>
> Und auch bei "richtigen" Anwendungen wird man nicht schneller fertig
> wenn mehr Rechenleistung da ist.

Das klassische Beispiel bei "richtigen" Anwendungen ist SAP. Ich hatte
seinerzeit, so um 2000 +- ein paar wenige Jahre, beruflich zu tun mit
Unternehmen, die von SAP/R2 auf SAP/R3 umstellten. Die
Betriebswirtschaft war (damals, also bei den ersten R3-Versionen) nicht
groß unterschiedlich zu R2, aber es war halt bunt und ansatzweise
mausbedienbar. Die reine CPU-Leistung der Datenbank- und
Applicationserver war um 2 bis 3 Größenordnungen höher als die der alten
Mainframes, die da abgelöst wurden, aber trotzdem waren alle davon
überzeugt, dass "SAP" die Abkürzung für "Sanduhr-Anzeige-Programm" sei.
Auch der Plattenplatzbedarf wuchs bei dieser Umstellung ungefähr um den
Faktor 100 (und in den Folgejahren nochmals um den Faktor 10);
zugegebenermaßen war aber die Hardware nicht mehr viel teurer als vorher
der dicke Mainframe.

Damals habe ich aber vor allem was gelernt, wie man um verschwenderische
Hardwarenutzung herumargumentiert. Damals gab es eine geflügelten
Lehrsatz: der Ressourcenbedarf einer SAP-Installation ist nach dem
upgrade der Version um 30% höher. Genauer gesagt, es ist um 30% höher
als vorher geplant, und das gilt auch, wenn man diesen Lehrsatz bei der
Planung schon berücksichtigt hat. Nur aus SAP-Sicht galt das alles
nicht, denn die messen die Leistung eines Systems in der Einheit SAPS
(der Leistungsbedarf eines Standardusers). Und natürlich braucht ein
Standarduser vor und nach der Umstellung genau ein SAPS Leistung. Nur
die Hardware wird immer schwächer - ein System, das vorher 200 User
tragen konnte, also eine Leistung von 200 SAPS hatte, leistete nachher
nur noch 150 SAPS.

[Thomas Koenig]

Kay Martinen <use...@martinen.de> schrieb:

> Am 13.01.24 um 15:16 schrieb Marcel Mueller:
>> Am 10.01.24 um 23:11 schrieb Andreas Kohlbach:
>>> Und einen "Apollo-Computer" hat man seit Jahrzehnten in seiner
>>> Hosentasche.
>>
>> Meinst Du HP-Apollo, also für die ganz großen Hosentaschen?
>
> Ich fürchte er meine den Apollo Guidance Computer (AGC). Das große mit
> dem fädelkernspeicher und der "Fernbedienung" (DSKY?). :)

NOR is all that you need!

Das war damals die absolute Spitze des Bedienkomforts, dass man
da Zahlen angezeigt hat und Zahlen eintippen konnte.

Nix Lochstreifen irgendwo reinstecken...

[Ignatios Souvatzis]

Diedrich Ehlerding wrote:
> Ulli Horlacher meinte:
>
>>>> DAS klingt mir nun eher nach ein konzeptionellem Problem :-)
>>>> Zu meiner Studi-Zeit hat DER Zentral-Computer 12 MB RAM und es
>>>> reichte fuer ALLE. Gleichzeitig. Interaktiv.
>>>
>>> Na ja - die konnten damit auch nicht viel machen.
>>
>> Es reichte fuer (fast) alle wissenschaftliche Anwendungen einer
>> grossen Universitaet.
>> Es gab nur noch wenige zusaetzliche Spezial-Workstations in den
>> Instituten, hauptsaechlich fuer Grafik.

>
> Ja. Heute haben wir CPU-Leistung am Arbeitsplatz, die um mehrere
> Größenordnungen höher ist als damals für die ganze Uni reichte. Die
> Briefe, die man heute auf dem Computer schreibt, werden aber nicht
> schneller fertig als damals an der Schreibmaschine - sie werden nur
> bunter und schöner.

IBTD. Bunter, ja, oft aber hässlicher und nicht lesbarer.

Die Corporate Identity meines AG verlangt nach einem Font, bei dem
l und I nicht unterscheidbar sind. Ein Latex-Style, den die Physiker
dafuer gebaut haben ,hat eine Option fuer Leute, die Formeln
brauchen, die einen serifen-behafteten Font verwendet. Aber mit
der Warnung, dass das dann die CI-Richtlinien bricht.

-is

[Ignatios Souvatzis]

Kay Martinen wrote:
> Am 11.01.24 um 18:14 schrieb Arno Welzel:
>> Stefan Möding, 2024-01-11 07:48:
>>
>>> Arno Welzel <use...@arnowelzel.de> writes:
>>>
>>>> Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
>>>> Das ist keinesfalls immer gegeben.
>>>
>>> Da läuft die Anwendung ja auch nur mit 5 Demo-Datensätzen.
>>
>> In meiner Welt nicht. Da gehört zur Abnahme der Software *zwingend* auch
>> ein Lasttest dazu.

>>
>
> Mit 100% Last auf jedem Kern bis die Hardware kocht?

Das ist ja nicht der Sinn des ganzen. Nein, mit realistisch großen
Datensätzen, dann fällt auf, ob der geneigte Entwickler unnötigerweise
einen exponentiell (oder auch nur kubisch) wachsenden Algorithmus
irgendwo einsetzt oder sonst einen Engpass hineinkonstruiert hat.

-is

[Gerrit Heitsch]

On 1/12/24 11:29, Stefan Möding wrote:
>
> Das Streaming von Musik und Filmen ist ja das gleiche Thema. Ich behalte
> meine CDs/DVDs daher als Backup.

Die halten auch nicht ewig. Es ist eine gute Idee, die zu rippen und
damit in einer Form zu haben in der Backups kein Problem mehr sind.

Gerrit

[Gerrit Heitsch]

On 1/13/24 10:30, Michael Kraemer @ home wrote:
> Dennis Grevenstein wrote:
>
>> Ich persönlich habe z.B. keine LPs mehr, keine MCs, nur
>> wenige CDs. Mir ist mal meine damalige Lieblings-CD mitsamt dem
>> Autoradio gestohlen worden... Aber mp3s sind mir in 25 Jahren
>> noch keine verloren gegangen.
>
> Das verschiebt das Problem aber nur,
> denn auch die mp3's residieren auf einem $MEDIUM.

Ja, aber man kann sie problemlos auf $MEDIUM_NEU kopieren wenn $MEDIUM
am Verschwinden ist.

> Und man braucht ein $PROGAMM um sie auf einem $GERAET hoerbar abspielen
> zu koennen.

Die gibts in Soft- und Hardware überall. Erstere sogar teilweise mit
Source womit die Portierung auf $GERAET_NEU möglich wird.

Gerrit

[Gerrit Heitsch]

On 1/13/24 12:18, Dennis Grevenstein wrote:

> Das sind ja tatsächlich 2 verschiedene Dinge. Zum einen das Problem,
> dass die Musik zu spielen aufhört, wenn ich nicht mehr jeden Monat
> bezahle. Und zusätzlich das Problem des Angebots. Es gibt keine
> Garantie, dass mein Lieblings-content nicht irgendwann mal verändert,
> aus dem Angebot gelöscht oder an moderne Sensibilitäten angepasst
> wird. Darauf aufbauend dann das Problem des Zugangs, falls der
> Anbieter morgen entscheidet, nur noch bestimmte Systeme zu unterstützen
> oder eine neue Form von DRM verlangt. Dann könnte man auf einmal
> draußen bleiben müssen.

Kurz: Nur was du auf eigenen Systemen in einem DRM-freien Format hast
ist auch wirklich deins.

Gerrit

[Kay Martinen]

Am 13.01.24 um 16:36 schrieb Ignatios Souvatzis:

Würde dann nicht auch die Last auf der CPU immer höher werden, oder
wenn's nicht weiter geht, der Durchsatz einbrechen?

Ich hätte korrekter sein und stattdessen "bis die Software kocht"
schreiben sollen.

Die HW bremst sich ja schon eine weile lang selbst aus wenn's ihr zu
warm wird. Was dann allerdings; bei steigender Arbeitslast auch wieder
zum kochen neigt. Nein, nicht die HW, sondern den Prüfer (Ziel verfehlt
=neuprogrammieren) :-)

[Kay Martinen]

Am 13.01.24 um 18:11 schrieb Gerrit Heitsch:

Wenn man nicht zu hohe Ansprüche stellt gibt es noch eine Alternative.
So habe ich z.b. einige Marvel Blockbuster auf DVD. Aber wenn die im TV
laufen; vorzugsweise mal im ÖR mit HD; dann nehme ich sie doch gern noch
auf.

Das VIDEO_TS u.a. von der Scheibe auf die Platte kopieren ging hier
zwar, aber beim Abspielversuch war das Ergebnis variabel, von "Falsche
Datei erwischt" bis "geht nicht" über "Player mag das nicht" was so
alles dabei.

Welches Programm nimmt man denn da unter Linux das die DVD rippt und nur
EINE immer und mit allem abspielbare Datei produziert? Idealerweise auch
in HD wenn die Quelle das liefert und mit Mehreren Tonspuren - soweit
vorhanden.

Beim Aufnehmen aus dem FTA ist mir das Wumpe, aber wenn schon rippen
dann aber richtig ordentlich.

Und Backups davon habe ich bisher keine gemacht. Wozu auch wenn die
Original DVD vorhanden ist. Da sei "Napster-Mode" vor die weg zu
schmeißen. ;-)

[Dennis Grevenstein]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>
> Kurz: Nur was du auf eigenen Systemen in einem DRM-freien Format hast
> ist auch wirklich deins.

genau.

[Dennis Grevenstein]

Ignatios Souvatzis <u50...@bnhb484.de> wrote:
>
> Die Corporate Identity meines AG verlangt nach einem Font, bei dem
> l und I nicht unterscheidbar sind. Ein Latex-Style, den die Physiker
> dafuer gebaut haben ,hat eine Option fuer Leute, die Formeln
> brauchen, die einen serifen-behafteten Font verwendet. Aber mit
> der Warnung, dass das dann die CI-Richtlinien bricht.

auf so eine Idee muss man erstmal kommen ;-)

[Christian Garbs]

Mahlzeit!

Marcel Mueller <news.5...@spamgourmet.org> wrote:

> Es gibt eine alte Entwickler-Regel: first make it work, then make it
> fast.

Erste Regel der Optimierung: Don't.
Zweite Regel (für Profis): Not yet.

Das ist beides vermutlich weniger ernst gemeint, aber inhaltlich
sinnvoll ist "kein Optimieren ohne zu messen".

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Futurama - made from meat-by products

[Marcel Mueller]

Am 13.01.24 um 15:33 schrieb Kay Martinen:

> Am 13.01.24 um 15:16 schrieb Marcel Mueller:

>> IPC hat sich schon noch signifikant verbessert. Nur beim Takt ging es
>> seither deutlich langsamer.
> Quasi seitwärts. Bei gleichem Takt mehr nebenbei erledigen... 100 Kerne
> sind ja keine Seltenheit mehr. Nicht mainstream aber auch nicht
> exotisch. Welche Alte Anlage hatte so viele Rechenkerne und ab wann?

Naja, eine Niagara T2 von vor über 15 Jahren hatte auch schon 64
Threads, wobei die sich deutlich weniger Rechenwerke teilen mussten.


Marcel

[Kay Martinen]

Am 13.01.24 um 23:28 schrieb Andreas Kohlbach:

> On Sat, 13 Jan 2024 15:33:55 +0100, Kay Martinen wrote:
>>
>> Am 13.01.24 um 15:16 schrieb Marcel Mueller:
>>> Am 10.01.24 um 23:11 schrieb Andreas Kohlbach:
>>>> Und einen "Apollo-Computer" hat man seit Jahrzehnten in seiner
>>>> Hosentasche.
>>> Meinst Du HP-Apollo, also für die ganz großen Hosentaschen?
>

> Also ich will nicht wissen wie groß Dein Apollo ist, und in welcher
> Hosentasche er sich rumtreibt. ;-)

Man sagt doch "Platz ist in der kleinsten Hütte". Da wird das auch mit
den Hosentaschen funktionieren. In unsere passen nur Handys; und ein
kleiner Adonis zum Taschenpingpong spielen; aber bei Donald Trump paßt
auch noch ein Ego mit überbreite hinein. ;)

Der schleppt bestimmt auch keine Server oder Workstation mit sich rum,
der LÄSST rechnen.

Falls du auf den Griechischen Gott anspielst: Das der ein großes Gemächt
hätte kann ich zumindest bei WP nicht finden. Ob das eine UL ist?

>> Ich fürchte er meine den Apollo Guidance Computer (AGC). Das große mit
>> dem fädelkernspeicher und der "Fernbedienung" (DSKY?). :)
>

> Ja. Ich hatte angenommen, daran sollte man als erstes bei
> "Apollo-Computer" denken.

Wenn wir hier in einer Raumfahrtgruppe wären ganz bestimmt. Aber so
denken die meisten wohl eher an Apollo/Domain oder solche
Namensähnlichkeiten. Es mag auch nicht jeder ein Faible für Raumfahrt
haben, so wie ich.

[Gerrit Heitsch]

On 1/13/24 19:48, Kay Martinen wrote:
> Am 13.01.24 um 18:11 schrieb Gerrit Heitsch:
>> On 1/12/24 11:29, Stefan Möding wrote:
>>>
>>> Das Streaming von Musik und Filmen ist ja das gleiche Thema.  Ich
>>> behalte
>>> meine CDs/DVDs daher als Backup.
>>
>> Die halten auch nicht ewig. Es ist eine gute Idee, die zu rippen und
>> damit in einer Form zu haben in der Backups kein Problem mehr sind.
>
> Wenn man nicht zu hohe Ansprüche stellt gibt es noch eine Alternative.
> So habe ich z.b. einige Marvel Blockbuster auf DVD. Aber wenn die im TV
> laufen; vorzugsweise mal im ÖR mit HD; dann nehme ich sie doch gern noch
> auf.
>
> Das VIDEO_TS u.a. von der Scheibe auf die Platte kopieren ging hier
> zwar, aber beim Abspielversuch war das Ergebnis variabel, von "Falsche
> Datei erwischt" bis "geht nicht" über "Player mag das nicht" was so
> alles dabei.

Komisch... klappt hier gut. Wenn man VLC oder mplayer die .IFO-Datei zum
Abspielen gibt läuft der Film.

> Und Backups davon habe ich bisher keine gemacht. Wozu auch wenn die
> Original DVD vorhanden ist. Da sei "Napster-Mode" vor die weg zu
> schmeißen. ;-)

Von Wergwerfen hat keiner was gesagt.

Gerrit

[Stefan Möding]

Ignatios Souvatzis <u50...@bnhb484.de> writes:

> Die Corporate Identity meines AG verlangt nach einem Font, bei dem
> l und I nicht unterscheidbar sind. Ein Latex-Style, den die Physiker
> dafuer gebaut haben ,hat eine Option fuer Leute, die Formeln
> brauchen, die einen serifen-behafteten Font verwendet. Aber mit
> der Warnung, dass das dann die CI-Richtlinien bricht.

Ich hatte auch mal so einen Fall, wo alle Dokumente per Word-Vorlagen die
eigens für diese Firma entwickelten TrueType-Fonts genutzt haben. Ohne
die Fonts sah das natürlich Schei... aus. Dazu waren die Fonts mit einer
restriktiven Lizenz ausgestattet, so dass damit auch das Einbetten in PDFs
verhindert wurde.

--
Stefan

[Kay Martinen]

Am 13.01.24 um 18:17 schrieb Gerrit Heitsch:

> On 1/13/24 12:18, Dennis Grevenstein wrote:
>
>> Das sind ja tatsächlich 2 verschiedene Dinge. Zum einen das Problem,
>> dass die Musik zu spielen aufhört, wenn ich nicht mehr jeden Monat
>> bezahle. Und zusätzlich das Problem des Angebots. Es gibt keine
>> Garantie, dass mein Lieblings-content nicht irgendwann mal verändert,
>> aus dem Angebot gelöscht oder an moderne Sensibilitäten angepasst
>> wird. Darauf aufbauend dann das Problem des Zugangs, falls der
>> Anbieter morgen entscheidet, nur noch bestimmte Systeme zu unterstützen
>> oder eine neue Form von DRM verlangt. Dann könnte man auf einmal
>> draußen bleiben müssen.

Das früher übliche "aus dem Radio aufnehmen" ist ja mit Tools wie
Radiotracker oder Streamwriter auch deutlich einfacher geworden.

Man muß zwar öfter mal nacharbeiten und reingesabbel durch löschen der
schlechtesten Aufnahme aussondern aber ansonsten gehts.

(Wobei ich; zu u.g.; davon ausgehe das auch internet-radio GEMA Zahlt.
Wenn nicht sollte man das evtl. mal prüfen [Piratensender?])

> Kurz: Nur was du auf eigenen Systemen in einem DRM-freien Format hast
> ist auch wirklich deins.

+1 Genau darum (o.g.) werde ich kein Streaming-abo haben. Aber die
jeweiligen Anbieter unternehmen ja allesamt die größten Anstrengungen
einem möglichst jede legale Alternative zu vermiesen. Und es scheint als
wäre es ihnen sogar recht wenn sie potentielle Kunden dadurch eher in
die Illegalität drängen. Denn dann können sie umso härter Geschütze
auffahren.

Und zugleich verhungern die eigentlichen Künstler weil die Content-Mafia
ihnen nur Brotkrumen vor die Füße wirft.Bekommen die von obigen
Strafzahlungen überhaupt was ab?

Das ist Schon irgendwie analog zu den Bauern und ihren Protesten. DIE
stellen die Rohstoffe her die von den Lebensmittel-Konzernen gebraucht
werden. Aber wegen irgendwelcher "Gründe" bekommen die anscheinend eher
immer weniger für ihr "Produkt" haben aber dennoch Ausgaben und
Innovationen zu tätigen - weil der Verbraucher "Öko" will - oder die
Marketing-Fuzzies meinen "Öko" sei Hipp und verkaufe sich besser/teurer.

Hmm, Gibt es keine Biologisch-dynamisch-ökologisch angebaute Musik? :)

Themenbezug: Prozessleistung statt Prozessor-leistung. ;)

[Kay Martinen]

Am 14.01.24 um 08:52 schrieb Stefan Ram:

> Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:
>> Kurz: Nur was du auf eigenen Systemen in einem DRM-freien Format hast
>> ist auch wirklich deins.
>

> ... einem DRM-freien Format und mit ausreichend Sicherungskopien ...
>
> Ein Mann, der gerade 70 geworden ist, hat eine Wahrscheinlichkeit
> von zirka 3 Prozent, in seinem (laufenden) 71. Lebensjahr zu sterben.
> - Daher ist es für ihn wahrscheinlich angemessen, wenn das Risiko
> eines Verlusts nicht-lebenswichtiger Unterhaltungsmusik auf
> weniger als 0,03 Prozent in diesem Zeitraum reduziert wird,
> also auf ein Hunderstel der Wahrscheinlichkeit zu sterben.

So für sich gesehen ist das richtig. Der Verlust wichtiger
Körperfunktionen ist schlimmer. Lieblings-musik könnte nur den
Heilungsprozess psychologisch unterstützen, denke ich. Wenn er nicht tot
ist.

> Dann ist das Risiko der Trennung des Mannes von seiner
> Musiksammlung durch seine Sterbewahrscheinlichkeit dominiert;
> es wird durch eine zusätzliche Erhöhung der Sicherheit der
> Verfügbarkeit der Musiksammlung nicht mehr wesentlich reduziert.

[Advocatus Diaboli]

Ist das ein Vorschlag die Musiksammlung mit einem Kill-DRM Zu dongeln
das an den Tod ihres Besitzers gekoppelt ist?

User tot = Musiksammlung Sicher entfernen (J/J/ALLES)?

Welche Content-Mafia hat sich das ausgedacht? :)

Ich habe noch Alte 78'er Platten von meiner Tante. Teils aus ihrer
Jugend (z.b. Lachpolka, Fred Bertelsmann - Der lachende Vagabund)

Analog zu obiger Vermutung müßte ich vor meinem Ableben testamentarisch
festlegen da die bei meinem Tot vernichtet würden. Sonst könnte ich sie
ja der nächsten Generation weiter vererben und so weiter...

"Yogiii, dem Ranger wird das nicht gefallen!" ;-)

[Kay Martinen]

Am 14.01.24 um 08:34 schrieb Gerrit Heitsch:

> On 1/13/24 19:48, Kay Martinen wrote:
>> Am 13.01.24 um 18:11 schrieb Gerrit Heitsch:
>>> On 1/12/24 11:29, Stefan Möding wrote:
>>>>
>>>> Das Streaming von Musik und Filmen ist ja das gleiche Thema.  Ich
>>>> behalte
>>>> meine CDs/DVDs daher als Backup.
>>>
>>> Die halten auch nicht ewig. Es ist eine gute Idee, die zu rippen und
>>> damit in einer Form zu haben in der Backups kein Problem mehr sind.
>>
>> Wenn man nicht zu hohe Ansprüche stellt gibt es noch eine Alternative.
>> So habe ich z.b. einige Marvel Blockbuster auf DVD. Aber wenn die im TV
>> laufen; vorzugsweise mal im ÖR mit HD; dann nehme ich sie doch gern noch
>> auf.
>>
>> Das VIDEO_TS u.a. von der Scheibe auf die Platte kopieren ging hier
>> zwar, aber beim Abspielversuch war das Ergebnis variabel, von "Falsche
>> Datei erwischt" bis "geht nicht" über "Player mag das nicht" was so
>> alles dabei.
>
> Komisch... klappt hier gut. Wenn man VLC oder mplayer die .IFO-Datei zum
> Abspielen gibt läuft der Film.

Dann war's evtl. Kodi der hier ein Problem damit hat. Den benutze ich
sowieso lieber.

>> Und Backups davon habe ich bisher keine gemacht. Wozu auch wenn die
>> Original DVD vorhanden ist. Da sei "Napster-Mode" vor die weg zu
>> schmeißen. ;-)
>
> Von Wergwerfen hat keiner was gesagt.

Das klang; nebenan?; etwas anders.

[Kay Martinen]

Am 13.01.24 um 10:30 schrieb Michael Kraemer @ home:

> Dennis Grevenstein wrote:
>
>> Ich persönlich habe z.B. keine LPs mehr, keine MCs, nur
>> wenige CDs. Mir ist mal meine damalige Lieblings-CD mitsamt dem
>> Autoradio gestohlen worden... Aber mp3s sind mir in 25 Jahren
>> noch keine verloren gegangen.
>
> Das verschiebt das Problem aber nur,
> denn auch die mp3's residieren auf einem $MEDIUM.

> Und man braucht ein $PROGAMM um sie auf einem $GERAET hoerbar abspielen zu koennen.

> Eine bis ans Lebensende $SORGLOSLOESUNG gibt es bisher mE nicht.

Dafür gibt es auch Lösungen. Z.b. das man $PLAYER und $GERAET ebenso
archiviert wie $OS für $PLAYER. Warum sollten die Bits auf $MEDIUM_1
langsamer/schneller verrotten als auf $MEDIUM_2 mit der Software.

Und wenn $GERÄT die Grätsche macht könnte man immer noch
$VIRTUELLES_GERÄT auf $NEU_GERÄT simulieren. Dann muß man ggf. nur
zusätzlich auch noch $ALTEN_HYPERVISOR archivieren.

- Done -

$LEBENSENDE ist zudem zu 100% Subjekt-abhängig. $SORGLOSLOESUNG ebenso.

[Marcel Mueller]

Am 13.01.24 um 22:06 schrieb Christian Garbs:

> Erste Regel der Optimierung: Don't.
> Zweite Regel (für Profis): Not yet.
>
> Das ist beides vermutlich weniger ernst gemeint, aber inhaltlich
> sinnvoll ist "kein Optimieren ohne zu messen".

Genau das sorgt für Software, die weitgehend unabhängig von der
Anforderung immer alle verfügbaren Systemressourcen verbraucht, denn
vorher wird nicht optimiert.

Und ganz ehrlich, das mit dem immer Messen halte ich auch für
Zeitverschwendung. Das dauert oft länger als es einfach zu machen.

Natürlich gibt es diffizile Optimierungen, wo man wirklich messen muss,
vor allem, wenn man das Letzte raus quetschen will. Aber das ist ja
meist gar nicht der Punkt. Da geht es eher darum, sich mit den üblichen
80% zufrieden zu geben. Und erst wenn das nicht reicht, muss man gezielt
suchen, wo das Problem liegt.


Marcel

[Bernd Laengerich]

Am 14.01.2024 um 17:57 schrieb Marcel Mueller:

> Und ganz ehrlich, das mit dem immer Messen halte ich auch für
> Zeitverschwendung. Das dauert oft länger als es einfach zu machen.

Wie willst Du denn den Erfolg einer Optimierung bewerten, wenn es keine
Messungen dazu gibt?

Bernd

[Peter J. Holzer]

On 2024-01-14 16:57, Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Am 13.01.24 um 22:06 schrieb Christian Garbs:
>> Erste Regel der Optimierung: Don't.
>> Zweite Regel (für Profis): Not yet.
>>
>> Das ist beides vermutlich weniger ernst gemeint, aber inhaltlich
>> sinnvoll ist "kein Optimieren ohne zu messen".
>
> Genau das sorgt für Software, die weitgehend unabhängig von der
> Anforderung immer alle verfügbaren Systemressourcen verbraucht, denn
> vorher wird nicht optimiert.
>
> Und ganz ehrlich, das mit dem immer Messen halte ich auch für
> Zeitverschwendung. Das dauert oft länger als es einfach zu machen.

Ich habe es schon erlebt, dass jemand Tage damit zugebracht hat,
"Optimierungen" vorzunehmen und nachher nicht sagen konnte, ob das jetzt
irgendwas gebracht hat, weil er weder vorher noch nachher gemessen hat.

> Natürlich gibt es diffizile Optimierungen, wo man wirklich messen muss,
> vor allem, wenn man das Letzte raus quetschen will. Aber das ist ja
> meist gar nicht der Punkt. Da geht es eher darum, sich mit den üblichen
> 80% zufrieden zu geben.

Auch die 80 % erreicht man nicht, wenn man nicht weiß, wo man optimieren
soll.

hp

[Kay Martinen]

Am 14.01.24 um 18:41 schrieb Bernd Laengerich:

Tja, IMHO wurden genau zu diesem Zweck die Performance-Counter in die
CPUs hinein operiert.

Und wenn es Schadsoftware heute schon gelingt durch Timing-messungen
einen Crypto-schlüssel aus der laufenden CPU zu ziehen sollte das für
Software mit Intention doch kein Problem sein.

Man muß es natürlich wollen und irgendwer muß es bezahlen wollen. Was er
nur tut wenn es mehr Geld verspricht.

Ergo: Don't! Not Yet. ??? ;)

[Marcel Mueller]

Am 14.01.24 um 18:41 schrieb Bernd Laengerich:

Er interessiert mich nicht. Ich nehme einfach immer die für das
Zugriffsmuster geeigneten Datenstrukturen. Das wäre sicher nicht in
jedem Fall erforderlich, aber darüber nachdenken ist schon zu viel.


Marcel

[Marcel Mueller]

Am 14.01.24 um 19:28 schrieb Peter J. Holzer:

> On 2024-01-14 16:57, Marcel Mueller <news.5...@spamgourmet.org> wrote:
>> Und ganz ehrlich, das mit dem immer Messen halte ich auch für
>> Zeitverschwendung. Das dauert oft länger als es einfach zu machen.
>
> Ich habe es schon erlebt, dass jemand Tage damit zugebracht hat,
> "Optimierungen" vorzunehmen und nachher nicht sagen konnte, ob das jetzt
> irgendwas gebracht hat, weil er weder vorher noch nachher gemessen hat.

Das ist das andere Extrem. Wenn es wirklich lange dauert, sollte man
vorher schon einen guten Grund haben. Oft dauern einfache Optimierungen
aber nur Minuten; im Besonderen, wenn man sich den Umweg über die
unoptimierte Version spart.

>> Natürlich gibt es diffizile Optimierungen, wo man wirklich messen muss,
>> vor allem, wenn man das Letzte raus quetschen will. Aber das ist ja
>> meist gar nicht der Punkt. Da geht es eher darum, sich mit den üblichen
>> 80% zufrieden zu geben.
>
> Auch die 80 % erreicht man nicht, wenn man nicht weiß, wo man optimieren
> soll.

Nach meiner Erfahrung springen einen 90% der Kandidaten für Langsamkeit
schon im Quellcode förmlich an. Nur ein paar wenige treten an völlig
unerwarteten Stellen auf.


Marcel

[Kay Martinen]

Am 14.01.24 um 21:47 schrieb Marcel Mueller:

Darüber hab ich doch neulich erst was gelesen - das die meisten
Programmierer eben das nicht mehr tun. Du bist also die Ausnahme.

Und wie wählt man jetzt Datenstrukturen nach einem Zugriffsmuster und
was ist überhaupt konkret ein Zugriffsmuster?

Da denke ich eher an diese Tricks mit denen Sidechannelattacken daten
Exfiltrieren anhand von ...!

[Christian Garbs]

Mahlzeit!

Marcel Mueller <news.5...@spamgourmet.org> wrote:

> Am 13.01.24 um 22:06 schrieb Christian Garbs:

>> Erste Regel der Optimierung: Don't.
>> Zweite Regel (für Profis): Not yet.
>>
>> Das ist beides vermutlich weniger ernst gemeint, aber inhaltlich
>> sinnvoll ist "kein Optimieren ohne zu messen".
>
> Genau das sorgt für Software, die weitgehend unabhängig von der
> Anforderung immer alle verfügbaren Systemressourcen verbraucht, denn
> vorher wird nicht optimiert.

Das kommt vermutlich auf die Definition von "Optimieren" an:

Wenn ich für eine Stelle, wo das offensichtlich die passende
Datenstruktur ist, eine Hashtable benutze, statt linear ein Array zu
durchsuchen, ist das dann bereits eine Optimierung?
Oder nur gesunder Menschenverstand bzw. normales Programmierer-
Handwerk?

> Und ganz ehrlich, das mit dem immer Messen halte ich auch für
> Zeitverschwendung. Das dauert oft länger als es einfach zu machen.

"Messen" muss ja nicht heißen, dass Du Hotspots auf Source-Zeilenebene
aufspürst.

Aber einfach einer Vermutung hinterherzulaufen und dann zu sagen "ist
jetzt optimiert", ohne einmal einen echten Durchlauf gemacht zu haben,
klappt nur, wenn Du richtig vermutet hasst.

> Natürlich gibt es diffizile Optimierungen, wo man wirklich messen
> muss, vor allem, wenn man das Letzte raus quetschen will. Aber das
> ist ja meist gar nicht der Punkt. Da geht es eher darum, sich mit
> den üblichen 80% zufrieden zu geben. Und erst wenn das nicht reicht,
> muss man gezielt suchen, wo das Problem liegt.

Da sind wir einer Meinung und kommen zu unterschiedlichem Ergebnis :-)

Solange sich niemand beschwert oder das Monitoring anschlägt oder die
Batchlaufzeit spürbar zu lang ist, bin ich im 80%-Fall und fange nicht
an zu optimieren.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Wieso nennen die Chinesen ihre Frühlingsrollen so kompliziert,
wenn sie das R sowieso nicht sagen können?

[Bernd Laengerich]

Am 14.01.2024 um 21:47 schrieb Marcel Mueller:

> Er interessiert mich nicht. Ich nehme einfach immer die für das Zugriffsmuster
> geeigneten Datenstrukturen. Das wäre sicher nicht in jedem Fall erforderlich,
> aber darüber nachdenken ist schon zu viel.

Machst Du jetzt den Chuck Lallong? Oft weiß man doch vorher gar nicht welches
die optimale Zugriffsstruktur ist und wo die Gefahren lauern.
Ich hechele gerade Performanceauswirkungen nach Doppel- und Dreifachfehlern
hinterher, da hat vor Jahren als der Code geschrieben wurde niemand auch nur
im entferntesten dran denken können weil es die jetzigen Szenarien und
Datenmengen noch gar nicht gab.
Und wie war das noch mit Wahrscheinlichkeiten?
Kollege: "Das kommt bestimmt nur in 1 von 10Mio Fällen vor!"
Ich: "Ja, dann haben wir das ja täglich..."

Bernd

[Diedrich Ehlerding]

Kay Martinen meinte:

> Und wenn $GERÄT die Grätsche macht könnte man immer noch
> $VIRTUELLES_GERÄT auf $NEU_GERÄT simulieren. Dann muß man ggf. nur
> zusätzlich auch noch $ALTEN_HYPERVISOR archivieren.

Nee, der alte Hypervosor läuft auf dem neuen Gerät im Zweifel nicht. Man
braucht einen neuen Hypervisor, der in der Lage ist, die alte Hardware
zu emulieren.
>
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Kay Martinen]

Am 15.01.24 um 09:07 schrieb Diedrich Ehlerding:

> Kay Martinen meinte:
>
>> Und wenn $GERÄT die Grätsche macht könnte man immer noch
>> $VIRTUELLES_GERÄT auf $NEU_GERÄT simulieren. Dann muß man ggf. nur
>> zusätzlich auch noch $ALTEN_HYPERVISOR archivieren.
>
> Nee, der alte Hypervosor läuft auf dem neuen Gerät im Zweifel nicht. Man
> braucht einen neuen Hypervisor, der in der Lage ist, die alte Hardware
> zu emulieren.
>>

+ $OS ???

:)

[Peter J. Holzer]

Mit anderen Worten: Du verlässt Dich auf Dein Bauchgefühl. Das kann
täuschen (und wenn Du es nicht regelmäßig überprüfst, täuscht es sogar
sicher).

hp

[Diedrich Ehlerding]

Kay Martinen meinte:

>>> Und wenn $GERÄT die Grätsche macht könnte man immer noch
>>> $VIRTUELLES_GERÄT auf $NEU_GERÄT simulieren. Dann muß man ggf. nur
>>> zusätzlich auch noch $ALTEN_HYPERVISOR archivieren.
>>

>> Nee, der alte Hypervisor läuft auf dem neuen Gerät im Zweifel nicht.

>> Man braucht einen neuen Hypervisor, der in der Lage ist, die alte
>> Hardware zu emulieren.
>>>
>
> + $OS ???

Datenträger fürs Betriebssystem kann man archivieren. Oder man zieht ein
Image der Platte des $ALT_GERAET und spielt das dann in die VM ein.

[Arno Welzel]

Kay Martinen, 2024-01-11 18:34:

> Am 11.01.24 um 18:14 schrieb Arno Welzel:
>> Stefan Möding, 2024-01-11 07:48:
>>
>>> Arno Welzel <use...@arnowelzel.de> writes:
>>>
>>>> Das gilt nur, wenn der Entwickler immer die aller neueste Hardware hat.
>>>> Das ist keinesfalls immer gegeben.
>>>
>>> Da läuft die Anwendung ja auch nur mit 5 Demo-Datensätzen.
>>
>> In meiner Welt nicht. Da gehört zur Abnahme der Software *zwingend* auch
>> ein Lasttest dazu.
>>
>
> Mit 100% Last auf jedem Kern bis die Hardware kocht?

Wenn "die Hardware kocht" unter Last, dann ist sie fehlerhaft.

Nein, ich meine Lasttests, die sicherstellen, dass die die Software und
Umgebung, in der sie läuft, die geforderte Leistung sicherstellt. Und
das sind ggf. auch mal mindestens 1000 HTTP-Requests pro Sekunde inkl.
Anfragen an die Datenbank, in der einige TB an Daten liegen.


--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Kay Martinen, 2024-01-11 18:23:

[...]
> Und mir fällt hierbei auf das immer (nur) noch von "Entwicklern" die
> Rede ist, und nicht mehr von Programmierern.

Das liegt vielleich auch daran, dass Programmieren genau genommen eine
andere Tätigkeit als Entwickeln ist. Früher bedeutete das, dass man das
Programm, was ein Entwickler geschrieben hat, in den Computer übertragen
hat, ohne verstehen zu müssen, was das Programm eigentlich tut - z.B.
indem man den vorliegenden Quelltext auf Lochkarten übertragen hat, die
dann von einem Computer gelesen wurden.

> Liegt das NUR daran das es oft "Developer" heißt und übersetzt wird,
> oder sind die echten Programmierer ausgestorben? Vielleicht weil sie für
> X Zeilen Code länger brauchten als $Timeslot befielt - und die Qualität
> der Arbeit sowieso niemand mehr nach mißt (nicht kann oder will)?

Nein, "to develop" heißt "entwickeln" und "program" eben "programmieren".

Es gibt auch Programmierer außerhalb der IT, z.B. Programmierer von
Filmprogrammen im Kino oder auf Festivals. Die drehen auch nicht die
Flme selber, sondern sorgen nur dafür, dass die Vorführungen so gelegt
sind, dass die Filme auch alle in der vorgesehenen Zeit gezeigt werden
können.

[Marcel Mueller]

Am 15.01.24 um 19:00 schrieb Peter J. Holzer:

Das klappt ganz gut. Aber ich komme auch noch aus der Zeit, wo man
Datenträger schnarchlangsam waren, Speicher knapp und man DB-Kernels in
Assembler geschrieben hat.
Aber darum geht es ja gar nicht. Ich bin ja schon zufrieden, wenn man
den passenden Datensatz in den gerade zusammengesuchten Daten nicht
jedes einzelne mal per Schleife über alles sucht, sondern halt eine
Hashtable oder irgendeinen anderen assoziativen Container nutzt. Damit
trifft man durchaus auch nicht immer das Optimum, aber wenigstens ist es
nicht O(n²).


Marcel

[Marcel Mueller]

Am 14.01.24 um 22:36 schrieb Christian Garbs:

> Das kommt vermutlich auf die Definition von "Optimieren" an:
>
> Wenn ich für eine Stelle, wo das offensichtlich die passende
> Datenstruktur ist, eine Hashtable benutze, statt linear ein Array zu
> durchsuchen, ist das dann bereits eine Optimierung?

Im Prinzip, ja.

> Oder nur gesunder Menschenverstand bzw. normales Programmierer-
> Handwerk?

Wo ist der Unterschied?

>> Und ganz ehrlich, das mit dem immer Messen halte ich auch für
>> Zeitverschwendung. Das dauert oft länger als es einfach zu machen.
>
> "Messen" muss ja nicht heißen, dass Du Hotspots auf Source-Zeilenebene
> aufspürst.

Alleine die Testfälle zu präparieren und reproduzierbare Messbedingungen
zu schaffen, kostet oft schon unverhältnismäßig viel Zeit. Vor allem,
wenn Shared Resources, wie VM-Hosts oder Datenbanken im Spiel sind.

> Aber einfach einer Vermutung hinterherzulaufen und dann zu sagen "ist
> jetzt optimiert", ohne einmal einen echten Durchlauf gemacht zu haben,
> klappt nur, wenn Du richtig vermutet hasst.

Natürlich.
Aber ich will ja auch keinen Prozessschritt Optimierung. Man sollte halt
gleich so optimal implementieren, wie es mit moderatem Aufwand möglich
ist. Damit hält man sich viele, gleichwohl nicht alle
Optimierungsanforderungen vom Hals.
In Memory klappt das fast immer, bei relationalen Datenbanken eher so
lala. Die machen was sie wollen, selbst bei identischen Daten und Abfragen.

> Solange sich niemand beschwert oder das Monitoring anschlägt oder die
> Batchlaufzeit spürbar zu lang ist, bin ich im 80%-Fall und fange nicht
> an zu optimieren.

Ich habe einfach zu viele, dumme Optimierungen machen müssen. Darunter
waren auch Batch-Läufe, die mehr als 4 Wochen brauchen. Und wenn dann
jeden Monat ein neuer fällig ist, wird es allmählich eng mit
Wartungsintervallen. Als ich fertig war, waren es noch 20 Minuten.
In der letzten Firma, ist mir in den ersten Tagen tierisch auf den
Zeiger gegangen, dass die Software zum Starten immer über 3 Minuten
braucht. In einem halben Tag war es zumindest weniger als die Hälfte -
bei weitgehend unbekanntem Code. Das hat man doch bei 10 Entwicklern,
die ständig Compilieren und neu starten in kürzester Zeit wieder raus.
Und da war mutmaßlich auch nichts dabei, was man nicht hätte gleich
richtig machen können. Mittlerweile sind wir trotz komplexer gewordener
Anwendung bei 20 Sekunden. Da habe ich immer mal den einen oder anderen
"Beifang" optimiert, wenn Änderungen anstanden.


Marcel

[Marcel Mueller]

Am 13.01.24 um 16:09 schrieb Diedrich Ehlerding:
> Das klassische Beispiel bei "richtigen" Anwendungen ist SAP. Ich hatte
> seinerzeit, so um 2000 +- ein paar wenige Jahre, beruflich zu tun mit
> Unternehmen, die von SAP/R2 auf SAP/R3 umstellten. Die
> Betriebswirtschaft war (damals, also bei den ersten R3-Versionen) nicht
> groß unterschiedlich zu R2, aber es war halt bunt und ansatzweise
> mausbedienbar. Die reine CPU-Leistung der Datenbank- und
> Applicationserver war um 2 bis 3 Größenordnungen höher als die der alten
> Mainframes, die da abgelöst wurden, aber trotzdem waren alle davon
> überzeugt, dass "SAP" die Abkürzung für "Sanduhr-Anzeige-Programm" sei.
> Auch der Plattenplatzbedarf wuchs bei dieser Umstellung ungefähr um den
> Faktor 100 (und in den Folgejahren nochmals um den Faktor 10);
> zugegebenermaßen war aber die Hardware nicht mehr viel teurer als vorher
> der dicke Mainframe.

Man kann SAP viel vorwerfen, aber wenn man lieb zu dem ist, kann man da
sogar ziemlich gute Performance raus holen. Vor allem in puncto
Skalierbarkeit sind die ganz vorne dabei. Mag sein, dass das in der
Anfangszeit von R3 noch nicht so war. Ich war einige Jahre später
unterwegs, so eher in der Zeit 6.20 bis 7.50.
Fakt ist allerdings auch, dass da viel räudiger Code existiert, von SAP
ausgelieferter einschließlich. Und da kommt eben genauso Mist raus, wie
in anderen Plattformen. Ein schneller Kernel ist halt nur die halbe Miete.

Wir hatten mal eine Anwendung auf einem Webserver (nicht SAP). Das war
eine selber gehäkelte In-Memory Dokumenten-DB, also sauschnell, aber
faktisch trotzdem I/O-bound. Was soll ich sagen, die hat um die 10k
Dokumente/s aus der Persistenzschicht in den Speicher gepumpt. Die
Anwendung hatte in ihrem Datenmodell aber auch Daten aus Fremdsystemen,
die Online geladen wurden. Aus SAP kamen immer noch um die 1000
Dokumente/s - durchaus ordentlich für einen vergleichsweise komplexen
FUBA. Nur ein anderes System, auf LAMP-Basis, das hat mit 10/s alles
runter gezogen. Vor allem hat letzteres überhaupt nicht skaliert.
Während man bei den ersten beiden durch Parallelisierung problemlos
nochmal einen Faktor 10 holen konnte, wurde es bei der LAMP Kiste bei
einem halben Dutzend Requests schon langsamer als mit einem, trotz 16
CPU-Kernen.
Der Webserver war übrigens eine Hasenkiste. VM mit 2 Kernen und 8GB RAM,
in das dank Deduplication ein vielfach höherer Datenbestand reingeladen
werden konnte. Mehr als 10% CPU Last hatte der eher selten. Und Speicher
war üblicherweise auch noch 1/3 frei.


Marcel

[Marcel Mueller]

Am 13.01.24 um 16:32 schrieb Ignatios Souvatzis:

> Die Corporate Identity meines AG verlangt nach einem Font, bei dem
> l und I nicht unterscheidbar sind.

So was ähnliches hatten wir auch mal. Der Font kam halt von der
Druckmaschine, und konnte da auch etwas. Aber auf dem Rechner, mit
damals 1/10 der Auflösung sah das einfach unmöglich und auch schlecht
lesbar aus.


Marcel

[Michael Kraemer]

On 14.01.2024 16:20, Kay Martinen wrote:

>
> Dafür gibt es auch Lösungen. Z.b. das man $PLAYER und $GERAET ebenso
> archiviert wie $OS für $PLAYER. Warum sollten die Bits auf $MEDIUM_1
> langsamer/schneller verrotten als auf $MEDIUM_2 mit der Software.
>
> Und wenn $GERÄT die Grätsche macht könnte man immer noch
> $VIRTUELLES_GERÄT auf $NEU_GERÄT simulieren. Dann muß man ggf. nur
> zusätzlich auch noch $ALTEN_HYPERVISOR archivieren.
>
> - Done -

Einklich will ich nur $MUSIK hören. Minimalinvasiv.