Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #49977 > unrolled thread
| Started by | "F. W." <me@home.invalid> |
|---|---|
| First post | 2025-05-16 07:53 +0200 |
| Last post | 2025-05-20 07:57 +0200 |
| Articles | 20 on this page of 184 — 17 participants |
Back to article view | Back to de.alt.folklore.computer
COMAL "F. W." <me@home.invalid> - 2025-05-16 07:53 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-16 10:45 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 07:59 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-19 09:36 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 11:27 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 11:40 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-19 14:59 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 15:58 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-19 16:37 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-05-31 10:16 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-01 17:19 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-01 23:57 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-02 08:16 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-02 12:56 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-02 17:10 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-04 11:54 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-04 13:16 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-08 22:19 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-09 09:47 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-06-09 16:38 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-09 12:06 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-09 14:59 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-09 14:02 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-10 08:08 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 09:36 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-10 12:10 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 18:41 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 21:03 +0000
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-06-11 07:01 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 18:37 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-10 18:49 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 20:52 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 07:22 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 05:51 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 08:15 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-11 08:04 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 11:41 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-06-12 12:47 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 16:50 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 17:13 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-12 07:41 +0200
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-12 08:22 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 19:41 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 20:00 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-13 08:20 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 16:55 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 10:45 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 09:24 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 11:29 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 09:36 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 11:41 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-14 14:37 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 14:41 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-14 15:01 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 13:25 +0000
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-06-14 21:20 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-14 21:52 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 07:42 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-14 16:13 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 00:49 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-15 11:09 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 17:01 +0200
Re: COMAL "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-06-16 08:56 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-17 07:03 +0000
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-06-14 21:20 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-14 21:58 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 00:51 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:40 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:29 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:16 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-17 08:44 +0000
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-14 14:34 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 13:23 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 13:05 +0000
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-15 13:17 +0000
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 13:43 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-15 16:52 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 15:32 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-15 21:25 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-16 07:00 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-16 18:38 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 19:23 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 18:08 +0000
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 21:31 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-16 06:56 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-15 21:32 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 22:22 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-16 06:58 +0000
Re: COMAL Peter Müller <invalid@invalid.invalid> - 2025-06-16 19:13 +0200
Re: COMAL Stefan Reuther <stefan.news@arcor.de> - 2025-06-16 18:25 +0200
Re: COMAL Arno Welzel <usenet@arnowelzel.de> - 2025-06-15 17:02 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-06-15 19:08 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-17 10:58 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 13:06 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 15:11 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 16:43 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 17:59 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 15:12 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 12:53 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 15:14 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 16:35 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-11 18:00 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-10 19:25 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 20:06 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-06-12 12:41 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-12 13:26 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-12 20:17 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-06-12 20:56 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-12 21:26 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-06-13 06:48 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 19:44 +0000
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-06-13 08:32 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-06-13 09:49 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-13 10:43 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-06-13 10:47 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 06:18 +0000
OOP (was: COMAL) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-10 18:57 +0200
Re: OOP Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-06-10 21:12 +0000
Re: OOP "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-11 12:33 +0200
Re: OOP Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-13 11:25 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 20:09 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-19 22:19 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 23:40 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-20 16:41 +0000
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-20 16:49 +0000
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-20 20:33 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-20 20:54 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-20 19:44 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-20 20:29 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-20 21:33 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-21 17:43 +0000
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-21 20:52 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-21 21:37 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-21 22:55 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 09:17 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 09:42 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 09:46 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 10:37 +0200
Re: COMAL Christian Corti <use@reply.to> - 2025-05-22 11:15 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 11:52 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 12:35 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 13:08 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 15:27 +0200
Re: COMAL Christian Corti <use@reply.to> - 2025-05-22 16:14 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 14:11 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-31 15:38 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 09:44 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 09:48 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 10:11 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 10:12 +0200
Re: COMAL "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-05-22 08:24 +0000
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 10:38 +0200
Re: COMAL Stefan Reuther <stefan.news@arcor.de> - 2025-05-22 18:45 +0200
Re: COMAL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-05-22 10:22 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-22 09:16 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 08:25 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-05-22 11:34 +0200
Re: COMAL Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-22 12:36 +0200
Re: COMAL "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-05-22 12:43 +0000
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 15:13 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 16:36 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-22 16:51 +0200
Re: COMAL Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-22 17:18 +0200
Re: COMAL Dietrich Clauss <dietrich@clauss-it.com> - 2025-05-22 20:31 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-23 03:54 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-23 13:56 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-23 15:04 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-23 16:23 +0200
Re: COMAL Christian Corti <use@reply.to> - 2025-05-26 11:59 +0200
Re: COMAL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-23 11:29 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-26 09:27 +0200
Re: COMAL Stefan Reuther <stefan.news@arcor.de> - 2025-05-20 18:47 +0200
Re: COMAL Andreas Eder <a_eder_muc@web.de> - 2025-05-27 21:56 +0200
Re: COMAL Thomas Koenig <tkoenig@netcologne.de> - 2025-05-31 13:19 +0000
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-16 11:53 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 08:01 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 08:14 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 08:51 +0200
Re: COMAL Eric Bruecklmeier <u@5i7.de> - 2025-05-19 09:05 +0200
Re: COMAL Kay Martinen <usenet@martinen.de> - 2025-05-19 09:02 +0200
Re: COMAL "F. W." <me@home.invalid> - 2025-05-19 09:20 +0200
Re: COMAL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 19:59 +0200
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-05-20 07:48 +0200
Re: COMAL Eric Bruecklmeier <nil@nil.nil> - 2025-05-20 07:57 +0200
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Eric Bruecklmeier <u@5i7.de> |
|---|---|
| Date | 2025-06-15 11:09 +0200 |
| Message-ID | <mb7gupFqcgtU1@mid.individual.net> |
| In reply to | #50749 |
Am 15.06.2025 um 00:49 schrieb Arno Welzel: > Eric Bruecklmeier, 2025-06-14 16:13: > >> Am 14.06.2025 um 15:01 schrieb Arno Welzel: >>> Eric Bruecklmeier, 2025-06-14 14:41: >>> >>>> Am 14.06.2025 um 14:37 schrieb Arno Welzel: >>> [...] >>>>> Wobei viele "interpretierte" Sprachen wie Ruby, JavaScript oder PHP zur >>>>> Laufzeit erstmal übersetzt werden in einer deutlich effizientere Form, >>>>> was dann auch als "just in time compiler" bezeichnet wird. In diese Form >>>>> ist der Code dann oft gar nicht mehr so viel langsamer, als reine >>>>> binaries - zumal, wenn der Code nur genutzt wird, um Funktionen aus >>>>> Libraries zu nutzen, die ihrerseits in C oder C++ geschrieben wurden. >>>> >>>> Völlig klar, aber einen Performance-sensiblen Gerätetreiber würde ich >>>> trotzdem nicht in Ruby schreiben. Abgesehen davon hängt die Performance >>>> dann auch immer von der konkreten Ruby VM ab. >>> >>> "Performance-sensibler Gerätetreiber" ist aber auch ein sehr >>> spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >>> Sprachen bezüglich Performance sehr gut aus. >>> >> >> ja - und nun? > > Und nun kann man alles, was nicht "Performance-sensibel" ist, auch gut > in Ruby, JavaScript, PHP, C# etc. schreiben. Das ist richtig, hat niemand angezweifelt und war von Anfang an klar. Nicht klar ist mir hingegen, was Du damit sagen willst.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-15 17:01 +0200 |
| Message-ID | <mb85iaFtobhU1@mid.individual.net> |
| In reply to | #50756 |
Eric Bruecklmeier, 2025-06-15 11:09: > Am 15.06.2025 um 00:49 schrieb Arno Welzel: [...] >> Und nun kann man alles, was nicht "Performance-sensibel" ist, auch gut >> in Ruby, JavaScript, PHP, C# etc. schreiben. > > Das ist richtig, hat niemand angezweifelt und war von Anfang an klar. > Nicht klar ist mir hingegen, was Du damit sagen willst. Wenn ohnehin alles klar ist - gar nichts. Man braucht halt nicht immer "High-Performance-Code" - das war auch klar und die ganze Diskussion dazu ist komplett sinnfrei, wie jede Diskussion über Dinge, die ohnehin bekannt sind. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> |
|---|---|
| Date | 2025-06-16 08:56 +0000 |
| Message-ID | <mba4ipF932fU2@mid.individual.net> |
| In reply to | #50783 |
Arno Welzel <usenet@arnowelzel.de> wrote: >Eric Bruecklmeier, 2025-06-15 11:09: > >> Am 15.06.2025 um 00:49 schrieb Arno Welzel: >[...] >>> Und nun kann man alles, was nicht "Performance-sensibel" ist, auch gut >>> in Ruby, JavaScript, PHP, C# etc. schreiben. >> >> Das ist richtig, hat niemand angezweifelt und war von Anfang an klar. >> Nicht klar ist mir hingegen, was Du damit sagen willst. > >Wenn ohnehin alles klar ist - gar nichts. Man braucht halt nicht immer >"High-Performance-Code" - das war auch klar und die ganze Diskussion >dazu ist komplett sinnfrei, wie jede Diskussion über Dinge, die ohnehin >bekannt sind. "High-Performance" kann für mich auch bedeuten, daß ich ein Problem schnell gelöst bekomme. Da hat z.B. Python den Vorteil, daß es eine Unmenge fertiger Module gibt. In C oder C++ muss ich u.U. diese erst selber entwickeln, was natürlich dauert. -- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-17 07:03 +0000 |
| Message-ID | <102r3v9$27oma$1@dont-email.me> |
| In reply to | #50816 |
Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> schrieb: > Arno Welzel <usenet@arnowelzel.de> wrote: >>Eric Bruecklmeier, 2025-06-15 11:09: >> >>> Am 15.06.2025 um 00:49 schrieb Arno Welzel: >>[...] >>>> Und nun kann man alles, was nicht "Performance-sensibel" ist, auch gut >>>> in Ruby, JavaScript, PHP, C# etc. schreiben. >>> >>> Das ist richtig, hat niemand angezweifelt und war von Anfang an klar. >>> Nicht klar ist mir hingegen, was Du damit sagen willst. >> >>Wenn ohnehin alles klar ist - gar nichts. Man braucht halt nicht immer >>"High-Performance-Code" - das war auch klar und die ganze Diskussion >>dazu ist komplett sinnfrei, wie jede Diskussion über Dinge, die ohnehin >>bekannt sind. > > "High-Performance" kann für mich auch bedeuten, daß ich ein > Problem schnell gelöst bekomme. Das ist nicht die übliche Definition :-) > Da hat z.B. Python den Vorteil, > daß es eine Unmenge fertiger Module gibt. In C oder C++ muss > ich u.U. diese erst selber entwickeln, was natürlich dauert. Stimmt, und für ein Wegwerf-Skript natürlich nicht verkehrt. Falls es was längerfrstiges werden soll, was die nächste Python-Version überlebt (weshalb du dann udaten musst), dann kann natürlich irgendeine inkomptible Änderung in dem ganzen Modulbaum dir erstmal alles zerschießen. Random Code aus dem Internet ist nicht immer die beste Lösung, hängt halt davon ab.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2025-06-14 21:20 +0200 |
| Message-ID | <102ki2d$1gvlu$1@news1.tnib.de> |
| In reply to | #50729 |
ram@zedat.fu-berlin.de (Stefan Ram) wrote: >Arno Welzel <usenet@arnowelzel.de> schrieb oder zitierte: >>"Performance-sensibler Gerätetreiber" ist aber auch ein sehr >>spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >>Sprachen bezüglich Performance sehr gut aus. > > Gerätetreiber werden oft von von Unternehmen angestellten > Programmierern geschrieben, wo die Programmiersprache oft bereits > von den Vorgesetzten oder der Unternehmenskultur vorgegeben wird. Oder von dem Projekt wofür der Gerätetreiber gedacht ist. Wieviele Gerätetreiber gibt es in Linux, die nicht in C geschrieben sind? Grüße Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-14 21:58 +0200 |
| Message-ID | <slrn104rl3o.1lvfd.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50743 |
On 2025-06-14 21:20, Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>> Gerätetreiber werden oft von von Unternehmen angestellten
>> Programmierern geschrieben, wo die Programmiersprache oft bereits
>> von den Vorgesetzten oder der Unternehmenskultur vorgegeben wird.
>
> Oder von dem Projekt wofür der Gerätetreiber gedacht ist. Wieviele
> Gerätetreiber gibt es in Linux, die nicht in C geschrieben sind?
Wenn ich das richtig sehe, drei: Einen Graphik- und zwei Netzwerktreiber
(Im Mainline-Tree 6.15.2; out-of-tree wird es wohl ein paar mehr geben).
hjp
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-15 00:51 +0200 |
| Message-ID | <mb6cnbFklhqU5@mid.individual.net> |
| In reply to | #50743 |
Marc Haber, 2025-06-14 21:20: > ram@zedat.fu-berlin.de (Stefan Ram) wrote: >> Arno Welzel <usenet@arnowelzel.de> schrieb oder zitierte: >>> "Performance-sensibler Gerätetreiber" ist aber auch ein sehr >>> spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >>> Sprachen bezüglich Performance sehr gut aus. >> >> Gerätetreiber werden oft von von Unternehmen angestellten >> Programmierern geschrieben, wo die Programmiersprache oft bereits >> von den Vorgesetzten oder der Unternehmenskultur vorgegeben wird. > > Oder von dem Projekt wofür der Gerätetreiber gedacht ist. Wieviele > Gerätetreiber gibt es in Linux, die nicht in C geschrieben sind? Das hat aber weniger mit "performance-sensibel" zu tun als der historischen Entwicklung. C war halt die Sprache, die explizit für Unix entwickelt wurde. Da ging es aber eher um leichtere Portabilität auch von systemnahem Code und weniger um maximale Performance. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-06-17 10:40 +0200 |
| Message-ID | <mbcnv8FmkveU1@mid.individual.net> |
| In reply to | #50743 |
Am 14.06.25 um 21:20 schrieb Marc Haber: > ram@zedat.fu-berlin.de (Stefan Ram) wrote: >> Arno Welzel <usenet@arnowelzel.de> schrieb oder zitierte: >>> "Performance-sensibler Gerätetreiber" ist aber auch ein sehr >>> spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >>> Sprachen bezüglich Performance sehr gut aus. >> >> Gerätetreiber werden oft von von Unternehmen angestellten >> Programmierern geschrieben, wo die Programmiersprache oft bereits >> von den Vorgesetzten oder der Unternehmenskultur vorgegeben wird. > > Oder von dem Projekt wofür der Gerätetreiber gedacht ist. Wieviele > Gerätetreiber gibt es in Linux, die nicht in C geschrieben sind? Die Schnittstellen passen zu C. Auch wenn in struct die Zuordnung zu Speicherlayout nicht offiziell festliegt. Gut sichtbar ist das für Tastatur und Maus in SDL Da können die Werte angzeigt werden. Die andere Seite wären Tastatur und Mausemulatoren über Arduino. Auch da gibt es sichtbare Schnittstellen, welche byte Folgen übertragen werden. Dazwischen liegen vermutlich wenige Zeilen Maschinencode und hardware "Verdrahtung". -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-06-17 10:29 +0200 |
| Message-ID | <mbcnbmFmht3U1@mid.individual.net> |
| In reply to | #50729 |
Am 14.06.25 um 16:49 schrieb Stefan Ram: > Arno Welzel <usenet@arnowelzel.de> schrieb oder zitierte: >> "Performance-sensibler Gerätetreiber" ist aber auch ein sehr >> spezifischer Bereich. Für die meisten Anwendungen reichen interpretierte >> Sprachen bezüglich Performance sehr gut aus. > > Gerätetreiber werden oft von von Unternehmen angestellten > Programmierern geschrieben, wo die Programmiersprache oft bereits > von den Vorgesetzten oder der Unternehmenskultur vorgegeben wird. Es gibt da verschieden Ebenen. Getrennte IO-Bereich, externe Bitfelder Zugriffe ( z.B. condition code Register), und interrupts sind in C nicht vorgesehen. Der Teil geht in Assembler. Die Ansteuerungen und Ergebnisse werden mit C verwaltet, so das es formatierte Zugriffe gibt. Das nächste wäre Schnittstellen zu anderen Sprachen. Statt C kann eventuell auch andere compiler Sprachen verwendet werden. > Neben der Geschwindigkeit muß ein Gerätetreiber oft auch eine > bestimmte binäre Schnittstelle (ABI) umsetzen, was mit einer > Sprache wie Python, so weit ich weiß, gar nicht möglich ist > (wenn man reines Python und nur Python verwenden will). Für den raspberry pi gibt es Python Schnittstellen für die Ansteuerung von IO Bits auf der Pin Doppelleiste. Die Bibliotheken in Python sind nach meiner Einschätzung überwiegend in C geschrieben. Python wäre zu langsam und Python hat direkt keine Pointer. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-06-17 10:16 +0200 |
| Message-ID | <mbcmj9Fmd6oU1@mid.individual.net> |
| In reply to | #50709 |
Am 14.06.25 um 11:24 schrieb Thomas Koenig: > Eric Bruecklmeier <u@5i7.de> schrieb: >> Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >>> Eric Bruecklmeier <nil@nil.nil> schrieb: >>>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >>> >>>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>>> noch sein :-) >>>> >>>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>>> ausschließlich in Ruby. >>> >>> Also keinen High-Performance code. >>> >>> Ich dagegen schreibe an einem Fortran-Compiler mit, Welches Fortran? Welche Optimierung? Eine Multiplikation ist heutzutage schneller als ein Speicherzugriff außerhalb vom cache. Und wenn erst wegen eines Sprunges der cache umgeladen wird.. > Ist es richtig, dass heute im Informatikunterricht die Studenten > normalerweise wenig bis gar nichts darüber lernen, wie man gute > Performance erreicht, Performance ist eine Frage wie weit man welche benötigt. > und nicht mal lernen, Assembler wenigstens zu lesen? Ob das sinnvoll ist? Wenn jeder Hersteller eigene Sprache hat. Ist der vom Z80 bei gleichen Befehlen anders als als für 8080? > (Assembler ist ein bisschen wie Latein, d.h. schreiben > ist selten nötig, aber Lesen können ist ein klarer Vorteil). Nun ja Operationen mit carry bit sind in C nicht vorhanden. ( Ist bei beliebig lange integer interessant. ) Interessant dürfte noch der Aufbau einer einfachen CPU sein. Nicht nur der ALU. Die Mikropogrammsteuerung habe ich mir noch nicht vollständig durchdacht. Die Bauteile dazu sind getaktete Zähler Zeichenspeicherregister und *ROMs für Kodierung. + Spezialsteuerung für die Initialisierung. In 10 Jahren werden vielleicht CPUs mit KIs entworfen. Aufgaben gerecht und Energie sparend. Compiler dann auch. > Bisher hat uns Moore's Law ja über weitere Abstraktionsebenen > hinweggeholfen, aber zumindest die Kurve der CPU-Performance über > der Zeit flacht so stark ab, dass das nicht mehr groß hilft. Stimmt Vergleichbares auch für Optimierungen? Wenn etwa Synchronisation teurer ist als serielle Ausführung? > Interpreter-Sprachen wie Python (was immer man auch von Python im > Speziellen halten möge, ich persönlich nicht viel, aus $GRUENDEN) > sind da natürlich noch eine weiter Faktor. Ich mag Python. Meine computer takten etliche Millionen mal schneller als mein Gehirn. Solange Berechnungen ein vielfaches weniger Zeit benötigten als die zugehörige Verwaltung, ist Python besser als Fortran. > Java und Julia haben wenigstens JIT-Compiler, die die Performance > auf einen kleinen Faktor gegenüber kompilierten Sprachen > heraufheben. Für Python gibt es Pseudocode ( .pyc Dateien ) Für die Umsetzung nach Maschinencode müsste der Datentyp ermittel werden, andernfalls würde es Typ abhängige code Bereiche geben. Bei C++ ( templates? ( Im Gegensatz zu #define) ) soll ja derartiges für große Übersetzungszeiten und große code Bereiche sorgen. Mein Hauptprogrammiersprache ist derzeit Python3. An 2. Stelle steht C Für einige Anwendungen sind noch bash und JvaScript vorhanden. Gelegentliche Weiterbildung findet bei mir noch in Clisp statt. Vielleicht werde ich für Spezialanwendungen auch mal Rust einsetzen. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-17 08:44 +0000 |
| Message-ID | <102r9sg$29321$1@dont-email.me> |
| In reply to | #50838 |
Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb: > Am 14.06.25 um 11:24 schrieb Thomas Koenig: >> Eric Bruecklmeier <u@5i7.de> schrieb: >>> Am 13.06.2025 um 18:55 schrieb Thomas Koenig: >>>> Eric Bruecklmeier <nil@nil.nil> schrieb: >>>>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >>>> >>>>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>>>> noch sein :-) >>>>> >>>>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>>>> ausschließlich in Ruby. >>>> >>>> Also keinen High-Performance code. >>>> >>>> Ich dagegen schreibe an einem Fortran-Compiler mit, > > Welches Fortran? gfortran. > Welche Optimierung? Die Frage verstehe ich nicht so ganz. Details siehe https://gcc.gnu.org/onlinedocs/gcc/ und https://gcc.gnu.org/onlinedocs/gfortran/ . >i Eine Multiplikation ist heutzutage schneller > als ein Speicherzugriff außerhalb vom cache. > Und wenn erst wegen eines Sprunges der cache umgeladen wird.. Ja. Und? > >> Ist es richtig, dass heute im Informatikunterricht die Studenten >> normalerweise wenig bis gar nichts darüber lernen, wie man gute >> Performance erreicht, > > Performance ist eine Frage wie weit man welche benötigt. Wenn man keine Ahnung hat, steht man halt im Wald, wenn sie benötigt wird... > >> und nicht mal lernen, Assembler wenigstens zu lesen? > > Ob das sinnvoll ist? Wenn jeder Hersteller > eigene Sprache hat. Ist der vom Z80 bei gleichen Befehlen > anders als als für 8080? Kennt man eine (und die grundlegenden Prinzipien), kann man andere schnell lernen. > >> (Assembler ist ein bisschen wie Latein, d.h. schreiben >> ist selten nötig, aber Lesen können ist ein klarer Vorteil). > > Nun ja Operationen mit carry bit sind in C nicht vorhanden. In reinem C kann man sich bei Additionen zunutze machen, dass, für unsigned-Werte, a + b < a heißt, dass ein Carry generiert wurde. Schlaue Compiler merken dass. Und dann gibt es auch noch entsprechende builtins. > ( Ist bei beliebig lange integer interessant. ) Jep, siehe gmp source. > > Interessant dürfte noch der Aufbau einer einfachen CPU sein. > Nicht nur der ALU. > Die Mikropogrammsteuerung habe ich mir noch nicht vollständig > durchdacht. Die Bauteile dazu sind getaktete Zähler State machines. > Zeichenspeicherregister und *ROMs für Kodierung. > + Spezialsteuerung für die Initialisierung. Gibt halt verschiedene Arten von Mikroprogrammierung - ich kann mir die Mikroarchitektur anschauen und überlegen, welche Impulse ich wann so setzen muss, damit das passiert, was die Instruktion sagt. Und dann gibt es noch the AMD way, wo x86-Instruktionen intern in eine oder mehrere RISC-ähnliche Intruktionen übersetzt weren. > In 10 Jahren werden vielleicht CPUs mit KIs entworfen. > Aufgaben gerecht und Energie sparend. > Compiler dann auch. Es gibt schon KI-gesteuertes Fuzzing. > >> Bisher hat uns Moore's Law ja über weitere Abstraktionsebenen >> hinweggeholfen, aber zumindest die Kurve der CPU-Performance über >> der Zeit flacht so stark ab, dass das nicht mehr groß hilft. > > Stimmt Vergleichbares auch für Optimierungen? Compiler sind, wenn es z.B. um die Ausnutzung von SIMD-Instruktionen geht, noch nicht so fürchterlich gut, da ist häufig mit Hand-Assembler ein ganzzahliger Faktor zu holen. > Wenn etwa Synchronisation teurer ist als serielle Ausführung? Ist ein Problem. Parallel Programming Is Hard (TM). >> Interpreter-Sprachen wie Python (was immer man auch von Python im >> Speziellen halten möge, ich persönlich nicht viel, aus $GRUENDEN) >> sind da natürlich noch eine weiter Faktor. > > Ich mag Python. Meine computer takten etliche Millionen mal > schneller als mein Gehirn. > Solange Berechnungen ein vielfaches weniger Zeit benötigten > als die zugehörige Verwaltung, ist Python besser als Fortran. Das hängt jetzt sehr von der Definition von "besser" ab :-) >> Java und Julia haben wenigstens JIT-Compiler, die die Performance >> auf einen kleinen Faktor gegenüber kompilierten Sprachen >> heraufheben. > > Für Python gibt es Pseudocode ( .pyc Dateien ) > Für die Umsetzung nach Maschinencode müsste der Datentyp > ermittel werden, andernfalls würde es Typ abhängige code > Bereiche geben. Bei C++ ( templates? ( Im Gegensatz zu #define) ) > soll ja derartiges für große Übersetzungszeiten > und große code Bereiche sorgen. Jit-Compiler gibt es (siehe oben). Wenn einer ein LLVM oder gcc-git - basiertes Python schreiben möchte, geht das im Prinzip, aber Python ist ein moving target und auch nicht als jit-Sprache entworfen. > Mein Hauptprogrammiersprache ist derzeit Python3. > An 2. Stelle steht C > Für einige Anwendungen sind noch bash und JvaScript vorhanden. > > Gelegentliche Weiterbildung findet bei mir noch in Clisp statt. > Vielleicht werde ich für Spezialanwendungen auch mal Rust einsetzen.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-06-14 14:34 +0200 |
| Message-ID | <mb58j7Ff0b7U1@mid.individual.net> |
| In reply to | #50699 |
Thomas Koenig, 2025-06-13 18:55: > Eric Bruecklmeier <nil@nil.nil> schrieb: >> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: > >>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>> noch sein :-) >> >> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >> ausschließlich in Ruby. > > Also keinen High-Performance code. > > Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high > performance ein zentraler Gedanke, und da überlegt man sich > halt schon, ob man unbedingt Klassen braucht. Die Sprache > bietet es allerdings an. Klassen an sich machen Code nicht unbedingt langsamer. Frühe C++-Compiler haben auch den Code aus C++ erstmal in C übersetzt, wo man dann schön gesehen hat, dass aus Klassen einfach nur anderer Code wurde, der aber nicht zwangsläufig langsamer ist. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-14 13:23 +0000 |
| Message-ID | <102jt4r$6ne5$1@dont-email.me> |
| In reply to | #50722 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > Thomas Koenig, 2025-06-13 18:55: > >> Eric Bruecklmeier <nil@nil.nil> schrieb: >>> Am 12.06.2025 um 22:00 schrieb Thomas Koenig: >> >>>> Und bei kompilierten? Ein bisschen effizient darf's ja auch >>>> noch sein :-) >>> >>> Dazu kann ich wenig beitragen - ich programmieren mittlerweile fast >>> ausschließlich in Ruby. >> >> Also keinen High-Performance code. >> >> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >> performance ein zentraler Gedanke, und da überlegt man sich >> halt schon, ob man unbedingt Klassen braucht. Die Sprache >> bietet es allerdings an. > > Klassen an sich machen Code nicht unbedingt langsamer. Frühe > C++-Compiler haben auch den Code aus C++ erstmal in C übersetzt, wo man > dann schön gesehen hat, dass aus Klassen einfach nur anderer Code wurde, > der aber nicht zwangsläufig langsamer ist. Klar haben die Compiler C-Code erzeugt, aber halt C-Code mit extra-Overhead für die Objektorientierung. Der vptr muss in dem Object gespeichert werden, und ich muss beim Aufruf einer Methode auch den vptr laden. Also zwei Load-Operationen und einen indirekten Sprung statt einem direkten Sprung. Kann natürlch sein, dass der Overhead nicht groß ins Gewicht fällt, aber er ist da.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-15 13:05 +0000 |
| Message-ID | <102mger$tvut$1@dont-email.me> |
| In reply to | #50722 |
Stefan Ram <ram@zedat.fu-berlin.de> schrieb: > ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte: >>Während die objektorientierte Programmierung aus Gründen >>der Flexibilität versucht, alles erst so spät wie möglich - >>zur Laufzeit - zu entscheiden, geht man in C++ seit längerem in >>genau die entgegengesetzte Richtung und versucht, so viel wie >>möglich so früh wie möglich - schon beim Compilieren - zu >>entscheiden. Ein extremes Beispiel wäre eine komplizierte >>Berechnung, für die das in C++ geschriebene Programm sofort das >>Ergebnis ausgibt, dessen Compilierung aber Stunden gedauert hat. > > Und wenn ein Programm einmal kompiliert aber tausendmal genutzt > wird, lohnt sich das. > > C++ ist damit so etwas wie ein statisches Gegenstück zu dem > dynamischen Python. Die können sich ganz gut ergänzen. C++ ist leider mittlerweile so groß und undhandlich geworden, dass es so gut wie niemand mehr komplett beherrscht... "It's not feature creep, it's a feature stampede."
[toc] | [prev] | [next] | [standalone]
| From | Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) |
|---|---|
| Date | 2025-06-15 13:17 +0000 |
| Message-ID | <7t684ec78ci34b51cn3e8%sfroehli@Froehlich.Priv.at> |
| In reply to | #50699 |
On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: > Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high > performance ein zentraler Gedanke, Wieso eigentlich? Gerade Compiler zählen zu den Dingen, bei denen für mich Performance so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange brauchen, dann gehe ich halt einen Kaffee trinken. Das *Ergebnis* des Compilerlaufs sollte hingegen möglichst performant sein. Servus, Stefan -- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich Offizieller Erstbesucher(TM) von mmeike Stefan - die faszinierendste Erleuchtung des Seins! (Sloganizer)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-15 13:43 +0000 |
| Message-ID | <102milj$uftp$1@dont-email.me> |
| In reply to | #50768 |
Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> schrieb: > On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: >> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >> performance ein zentraler Gedanke, > > Wieso eigentlich? > > Gerade Compiler zählen zu den Dingen, bei denen für mich Performance > so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange > brauchen, dann gehe ich halt einen Kaffee trinken. Das *Ergebnis* > des Compilerlaufs sollte hingegen möglichst performant sein. Darum geht es auch - Performance beim generierten Code. Wobei... Fortran ist mittlerweile auch eine sehr umfangreiche Sprache geworden, da ist auch noch mehr als genug Arbeit zu tun :-)
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-15 16:52 +0200 |
| Message-ID | <slrn104tngm.2j83e.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50768 |
On 2025-06-15 15:17, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
> On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote:
>> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high
>> performance ein zentraler Gedanke,
>
> Wieso eigentlich?
>
> Gerade Compiler zählen zu den Dingen, bei denen für mich Performance
> so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange
> brauchen, dann gehe ich halt einen Kaffee trinken.
Naja, das macht für die Arbeitweise schon einen Unterschied. Der
Cobol-Compiler, den ich in den 80er-Jahren verwendet habe, hat für einen
Compiler-Lauf (das Programm war nicht ganz klein) gute 20 Minuten
gebraucht. In der Zeit habe ich immer die nächsten 10 Seiten von
"The Moon is a Harsh Mistress" gelesen und war danach mit meinen
Gedanken natürlich woanders. Auf der anderen Seite habe ich versucht, so
selten wie möglich zu kompilieren und möglichst alle Fehler durch
Korrekturlesen vorher zu finden. Wenn ich hingegen einen Compiler habe,
der nur ein paar Sekunden braucht, kann ich compilieren und im Flow
bleiben. Eines der Design-Kriterien von Go war daher auch schnelle
Compile-Zeiten.
> Das *Ergebnis* des Compilerlaufs sollte hingegen möglichst performant
> sein.
Das ist hingegen oft nicht so wichtig.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-15 15:32 +0000 |
| Message-ID | <102mp1r$100ok$1@dont-email.me> |
| In reply to | #50782 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > On 2025-06-15 15:17, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote: >> On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote: >>> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high >>> performance ein zentraler Gedanke, >> >> Wieso eigentlich? >> >> Gerade Compiler zählen zu den Dingen, bei denen für mich Performance >> so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange >> brauchen, dann gehe ich halt einen Kaffee trinken. > > Naja, das macht für die Arbeitweise schon einen Unterschied. Der > Cobol-Compiler, den ich in den 80er-Jahren verwendet habe, hat für einen > Compiler-Lauf (das Programm war nicht ganz klein) gute 20 Minuten > gebraucht. Erinnert mich so ein bisschen an die Startup-Zeiten von Excel 365, mittlerweile... Aber war das unter MVS einem verwandten System? Ich hatte da ein ähnliches Problem bei Programmen, die eine bestimmte Graphiklibrary eingebunden hatten. Das Problem war da nicht der Compiler, sondern der Linker, das dauerte gerne mal eine Viertelstunde, sich die Dinge zu einem Programm zusammenzubinden. Das war in den Zeiten vor gnuplot, da gab es am Rechenzentrum eine 3D-Library für Konturplots und einen Laserdrucker. Den Grund habe damals nicht verstanden, war mir aber auch halbwegs egal - wenn man als Student auf Stundenbasis bezahlt wird :-) Und der Linker war offensichtlich so schlecht, dass IBM ihn irgendwann durch ein neu geschriebenes Programm ersetzt hat und sogar (Sakrileg!) den Programmnamen IEWL für das neue Programm verwendet hat, und as neue Programm war nicht bug-kompatibel zum ersten (2. Sakrileg!). Den alten bekommt man noch unter irgendeinem Buchstabengeschwurbel aufgerufen, übliche MVS-Programmnamen halt. >In der Zeit habe ich immer die nächsten 10 Seiten von > "The Moon is a Harsh Mistress" gelesen und war danach mit meinen > Gedanken natürlich woanders. Auf der anderen Seite habe ich versucht, so > selten wie möglich zu kompilieren und möglichst alle Fehler durch > Korrekturlesen vorher zu finden. Siehe dazu Brooks, "The Design of Design". Er schrieb, er hätte mit einem Kumpel als STudent das einzige von Anfang an fehlerfreie Programm seines Lebens geschrieben, als sie damals genau eine Chance hatten, auf die Maschine zu kommen. Das hatten sie in tagelanger Arbeit mit Bleistift, Papier und Gehirn debuggt. >Wenn ich hingegen einen Compiler habe, > der nur ein paar Sekunden braucht, kann ich compilieren und im Flow > bleiben. Eines der Design-Kriterien von Go war daher auch schnelle > Compile-Zeiten. Verleitet natürlich auch ein bisschen zum schlampigen Denken... > >> Das *Ergebnis* des Compilerlaufs sollte hingegen möglichst performant >> sein. > > Das ist hingegen oft nicht so wichtig. Für Fortran sehr häufig schon. Der Grund ist einfach: Der Rechenzeit-Hunger bei großen Rechnungen skaliert unbegrenzt. Doppelte Auflösung in jeder Raumrichtung ist gleich mal ein Faktor 8 in der Anzahl von Elementen, die man braucht. Bei der Geschichte (Parallel-Thread über Seymour Cray) der Supercomputer war, unabhängig von der Rechenleistung, die Laufzeit der Jobs mehr oder weniger konstant, weil die Leute sich immer die maximale Rechenzeit gegönnt haben, die gerade noch ging.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-06-15 21:25 +0200 |
| Message-ID | <slrn104u7ho.2polj.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50790 |
On 2025-06-15 17:32, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>> On 2025-06-15 15:17, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
>>> On Fri, 13 Jun 2025 18:55:35 Thomas Koenig wrote:
>>>> Ich dagegen schreibe an einem Fortran-Compiler mit, da ist high
>>>> performance ein zentraler Gedanke,
>>>
>>> Wieso eigentlich?
>>>
>>> Gerade Compiler zählen zu den Dingen, bei denen für mich Performance
>>> so gut wie gar keine Priorität hat. Soll er meinetwegen 10x so lange
>>> brauchen, dann gehe ich halt einen Kaffee trinken.
>>
>> Naja, das macht für die Arbeitweise schon einen Unterschied. Der
>> Cobol-Compiler, den ich in den 80er-Jahren verwendet habe, hat für einen
>> Compiler-Lauf (das Programm war nicht ganz klein) gute 20 Minuten
>> gebraucht.
>
> Erinnert mich so ein bisschen an die Startup-Zeiten von
> Excel 365, mittlerweile...
>
> Aber war das unter MVS einem verwandten System?
Nein, MS-DOS. 8086 mit 8 MHz in meinem Fall. Das Hauptproblem war, dass
der Compiler immer das gesamte Programm kompiliert hat. Im Gegensatz zu
C, wo man das Programm in kleine Translation Units zerlegen und (mit ein
bisschen Hilfe von make) nur die geänderten kompilieren konnte, war das
bei diesem Cobol-Compiler nicht möglich (oder zumindest nicht
praktikabel - ist lange her und die Details habe ich nicht mehr im
Kopf).
>>Wenn ich hingegen einen Compiler habe,
>> der nur ein paar Sekunden braucht, kann ich compilieren und im Flow
>> bleiben. Eines der Design-Kriterien von Go war daher auch schnelle
>> Compile-Zeiten.
>
> Verleitet natürlich auch ein bisschen zum schlampigen Denken...
Zweifellos.
>>> Das *Ergebnis* des Compilerlaufs sollte hingegen möglichst performant
>>> sein.
>>
>> Das ist hingegen oft nicht so wichtig.
>
> Für Fortran sehr häufig schon.
Ja, Fortran wird hauptsächlich für numerischen Code eingesetzt, da ist
die CPU das Bottleneck. Und die will man dann auch maximal ausnützen,
vor allem, was das SIMD-Zeug betrifft.
Die meisten Programme verbringen hingegen den Großteil ihrer Zeit mit
Warten. Das kann der Compiler nicht optimieren. (Es kann trotzdem
sinnvoll sein, den nicht-wartenden Teil zu optimieren, z.B. um den
Stromverbrauch zu minimieren oder um möglichst viele Instanzen des Codes
auf einer Maschine laufen zu lassen, aber in vielen Fällen macht das
keinen Unterschied.)
hjp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-06-16 07:00 +0000 |
| Message-ID | <102ofek$1fjfk$3@dont-email.me> |
| In reply to | #50799 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > On 2025-06-15 17:32, Thomas Koenig <tkoenig@netcologne.de> wrote: >> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: >>>> Das *Ergebnis* des Compilerlaufs sollte hingegen möglichst performant >>>> sein. >>> >>> Das ist hingegen oft nicht so wichtig. >> >> Für Fortran sehr häufig schon. > > Ja, Fortran wird hauptsächlich für numerischen Code eingesetzt, da ist > die CPU das Bottleneck. Und die will man dann auch maximal ausnützen, > vor allem, was das SIMD-Zeug betrifft. Tatsächlich ist es sehr häufig der Speicherzugriff das Bottleneck, oder auch der Overhead zur Parallelisierung. > Die meisten Programme verbringen hingegen den Großteil ihrer Zeit mit > Warten. Das kann der Compiler nicht optimieren. (Es kann trotzdem > sinnvoll sein, den nicht-wartenden Teil zu optimieren, z.B. um den > Stromverbrauch zu minimieren oder um möglichst viele Instanzen des Codes > auf einer Maschine laufen zu lassen, aber in vielen Fällen macht das > keinen Unterschied.) Oder halt um die Reaktionszeit niedrig zu halten, damit der Benutzer sich nicht zum Handkäs ärgert...
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web