Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #43223 > unrolled thread
| Started by | Diedrich Ehlerding <diedrich.ehlerding@t-online.de> |
|---|---|
| First post | 2024-01-10 16:32 +0100 |
| Last post | 2024-01-16 20:37 +0100 |
| Articles | 20 on this page of 176 — 29 participants |
Back to article view | Back to de.alt.folklore.computer
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Prozessorleistung einst und jetzt (was: Linux-Neuling) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-10 16:32 +0100
Re: Prozessorleistung einst und jetzt Michael Kraemer <m.kraemer@gsi.de> - 2024-01-10 17:17 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-10 18:05 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-10 18:43 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-10 22:57 +0100
Re: Prozessorleistung einst und jetzt Stefan Möding <Jan2024.5.kill-9@spamgourmet.com> - 2024-01-11 07:48 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-11 18:14 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-11 18:34 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-11 18:53 +0100
Re: Prozessorleistung einst und jetzt Markus Elsken <markus.elsken@ewetel.net> - 2024-01-11 23:50 +0100
Re: Prozessorleistung einst und jetzt Ignatios Souvatzis <u502sou@bnhb484.de> - 2024-01-13 15:36 +0000
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-13 18:56 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-15 21:09 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-11 08:29 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-11 18:17 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-11 18:23 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-11 19:28 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-11 21:17 +0100
Re: Prozessorleistung einst und jetzt Günter Frenz <usenet-01@guefz.de> - 2024-01-11 23:55 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-12 03:50 +0100
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-01-12 09:51 +0000
Re: Prozessorleistung einst und jetzt Stefan Möding <Jan2024.5.kill-9@spamgourmet.com> - 2024-01-12 11:29 +0100
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-01-12 14:15 +0000
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-12 16:32 +0000
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-01-12 22:03 +0000
Re: Prozessorleistung einst und jetzt Raimund Huemmer <ray@rayjoe.de> - 2024-01-13 09:49 +0100
Re: Prozessorleistung einst und jetzt Raimund Huemmer <ray@rayjoe.de> - 2024-01-13 09:57 +0100
Re: Prozessorleistung einst und jetzt Stefan Möding <Jan2024.5.kill-9@spamgourmet.com> - 2024-01-13 12:06 +0100
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-13 11:18 +0000
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-13 18:17 +0100
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-13 20:35 +0000
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-14 15:42 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-14 16:13 +0100
Re: Prozessorleistung einst und jetzt Ignatios Souvatzis <u502sou@bnhb484.de> - 2024-01-26 12:40 +0000
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-26 18:28 +0100
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-01-26 19:46 +0000
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-27 00:51 +0100
Re: Prozessorleistung einst und jetzt Markus Elsken <markus.elsken@ewetel.net> - 2024-01-27 18:18 +0100
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-27 13:03 +0100
Re: Prozessorleistung einst und jetzt "Peter Heirich" <talk.usenet@info21.heirich.name> - 2024-01-31 17:08 +0000
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-02-01 13:28 +0000
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-01 14:59 +0100
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-02-01 16:53 +0000
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-02-02 20:20 +0100
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-02-02 20:01 +0000
Re: Prozessorleistung einst und jetzt Markus Elsken <markus.elsken@ewetel.net> - 2024-02-02 23:21 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-02-02 23:50 +0100
Re: Prozessorleistung einst und jetzt poc@pocnet.net - 2024-02-03 11:38 +0000
Re: Prozessorleistung einst und jetzt Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-02-03 21:05 +0100
Re: Prozessorleistung einst und jetzt Markus Elsken <markus.elsken@ewetel.net> - 2024-02-01 20:37 +0100
Re: Prozessorleistung einst und jetzt Başar Alabay <alabay@gmx.net> - 2024-01-27 05:35 +0000
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-16 17:26 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-16 23:24 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-17 10:47 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-17 16:42 +0100
Re: Prozessorleistung einst und jetzt Joerg Walther <joerg.walther@magenta.de> - 2024-01-13 12:48 +0100
Re: Prozessorleistung einst und jetzt "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2024-01-13 10:30 +0100
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-13 10:19 +0000
Re: Prozessorleistung einst und jetzt Joerg Walther <joerg.walther@magenta.de> - 2024-01-13 12:53 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-13 18:15 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-14 16:20 +0100
Re: Prozessorleistung einst und jetzt Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-15 09:07 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-15 15:43 +0100
Re: Prozessorleistung einst und jetzt Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-15 19:25 +0100
Re: Prozessorleistung einst und jetzt Michael Kraemer <m.kraemer@gsi.de> - 2024-01-16 10:08 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-16 23:34 +0100
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-18 13:57 +0000
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-18 15:34 +0100
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-18 17:28 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-17 11:44 +0100
Re: Prozessorleistung einst und jetzt Michael Kraemer <m.kraemer@gsi.de> - 2024-01-17 11:54 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-17 16:46 +0100
Re: Prozessorleistung einst und jetzt tom nossen <news@nossen.org> - 2024-07-20 22:33 +0200
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-21 20:07 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-22 00:25 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-22 09:50 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-22 18:29 +0100
Re: Prozessorleistung einst und jetzt Joerg Walther <joerg.walther@magenta.de> - 2024-01-23 16:58 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-02-02 20:21 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-17 20:11 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-17 20:41 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-18 07:32 +0100
Re: Prozessorleistung einst und jetzt Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-01-18 08:41 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-18 09:29 +0100
Re: Prozessorleistung einst und jetzt Andreas Kohlbach <ank@spamfence.net> - 2024-01-18 17:39 -0500
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-21 20:09 +0100
Re: Prozessorleistung einst und jetzt Ignatios Souvatzis <u502sou@bnhb484.de> - 2024-01-26 12:38 +0000
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-26 14:15 +0000
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-26 17:42 +0100
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-26 17:35 +0000
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-26 20:10 +0100
Re: Prozessorleistung einst und jetzt Michael Welle <mwe012008@gmx.net> - 2024-07-19 21:01 +0200
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-07-20 07:27 +0200
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-13 18:11 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-13 19:48 +0100
Re: Prozessorleistung einst und jetzt Andreas Kohlbach <ank@spamfence.net> - 2024-01-13 17:33 -0500
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-14 08:34 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-14 16:23 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-16 17:28 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-17 11:46 +0100
Re: Prozessorleistung einst und jetzt Andreas Dau <dev.null@andreasdau.com> - 2024-07-20 22:53 +0200
Re: Prozessorleistung einst und jetzt tom nossen <news@nossen.org> - 2024-07-20 22:23 +0200
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-07-20 22:31 +0200
Re: Prozessorleistung einst und jetzt tom nossen <news@nossen.org> - 2024-07-20 22:50 +0200
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-07-21 08:18 +0200
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-15 21:14 +0100
Re: Prozessorleistung einst und jetzt Christian Garbs <mitch@cgarbs.de> - 2024-01-13 21:06 +0000
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-14 17:57 +0100
Re: Prozessorleistung einst und jetzt Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-01-14 18:41 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-14 20:31 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-14 21:47 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-14 22:05 +0100
Re: Prozessorleistung einst und jetzt Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-01-15 09:25 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-15 19:00 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-15 23:31 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-17 11:54 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-14 19:28 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-14 21:52 +0100
Re: Prozessorleistung einst und jetzt Christian Garbs <mitch@cgarbs.de> - 2024-01-14 21:36 +0000
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-15 23:54 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-17 11:58 +0100
Re: Prozessorleistung einst und jetzt Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-17 16:28 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-17 11:53 +0100
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-17 15:19 +0100
Re: Prozessorleistung einst und jetzt "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2024-01-11 11:44 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-11 18:31 +0100
Re: Prozessorleistung einst und jetzt Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-13 16:09 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-16 00:27 +0100
Re: Prozessorleistung einst und jetzt Marco Moock <mm+solani@dorfdsl.de> - 2024-01-10 17:35 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-10 18:10 +0100
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-10 21:23 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-10 21:39 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-10 23:04 +0100
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-11 08:50 +0100
Re: Prozessorleistung einst und jetzt mlelstv@serpens.de (Michael van Elst) - 2024-01-11 08:11 +0000
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-11 18:21 +0100
Re: Prozessorleistung einst und jetzt Markus Elsken <markus.elsken@ewetel.net> - 2024-01-11 00:36 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-11 10:14 +0100
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-10 20:17 +0100
Re: Prozessorleistung einst und jetzt Andreas Kohlbach <ank@spamfence.net> - 2024-01-10 17:11 -0500
Re: Prozessorleistung einst und jetzt Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-01-11 08:55 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-11 10:18 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-11 10:29 +0100
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-11 09:54 +0000
Re: Prozessorleistung einst und jetzt "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2024-01-11 11:36 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-11 15:04 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-11 18:29 +0100
Re: Prozessorleistung einst und jetzt Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-01-11 19:38 +0000
Re: Prozessorleistung einst und jetzt Andreas Kohlbach <ank@spamfence.net> - 2024-01-11 16:23 -0500
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-11 10:43 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-11 18:26 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-11 18:25 +0100
Re: Prozessorleistung einst und jetzt Andreas Kohlbach <ank@spamfence.net> - 2024-01-11 17:14 -0500
Re: Prozessorleistung einst und jetzt Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-01-12 20:51 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-12 22:31 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-17 12:02 +0100
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-17 15:24 +0100
Re: Prozessorleistung einst und jetzt Arno Welzel <usenet@arnowelzel.de> - 2024-01-21 20:13 +0100
Re: Prozessorleistung einst und jetzt Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-01-29 21:38 +0000
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-01-31 12:37 +0100
Re: Prozessorleistung einst und jetzt Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-02-02 13:15 +0000
Re: Prozessorleistung einst und jetzt Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-03 14:03 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-13 15:16 +0100
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-13 15:33 +0100
Re: Prozessorleistung einst und jetzt Thomas Koenig <tkoenig@netcologne.de> - 2024-01-13 15:56 +0000
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-13 22:36 +0100
Re: Prozessorleistung einst und jetzt Andreas Kohlbach <ank@spamfence.net> - 2024-01-13 17:28 -0500
Re: Prozessorleistung einst und jetzt Kay Martinen <usenet@martinen.de> - 2024-01-14 03:20 +0100
Re: Prozessorleistung einst und jetzt (was: Linux-Neuling) Ignatios Souvatzis <u502sou@bnhb484.de> - 2024-01-13 15:32 +0000
Re: Prozessorleistung einst und jetzt Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-01-13 20:39 +0000
Re: Prozessorleistung einst und jetzt Stefan Möding <Jan2024.5.kill-9@spamgourmet.com> - 2024-01-14 14:03 +0100
Re: Prozessorleistung einst und jetzt Ignatios Souvatzis <u502sou@bnhb484.de> - 2024-01-17 12:16 +0000
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-16 08:34 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-16 20:04 +0100
Re: Prozessorleistung einst und jetzt Marcel Mueller <news.5.maazl@spamgourmet.org> - 2024-01-16 20:31 +0100
Re: Prozessorleistung einst und jetzt "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-01-16 20:37 +0100
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Andreas Dau <dev.null@andreasdau.com> |
|---|---|
| Date | 2024-07-20 22:53 +0200 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <lg2mdcFu59aU1@mid.individual.net> |
| In reply to | #43411 |
On 17/01/2024 11:46, Arno Welzel wrote: > MakeMKV Genau so! cu, ada
[toc] | [prev] | [next] | [standalone]
| From | tom nossen <news@nossen.org> |
|---|---|
| Date | 2024-07-20 22:23 +0200 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <v7h6cg$3meqc$1@dont-email.me> |
| In reply to | #43333 |
Am 13.01.24 um 21:35 schrieb Dennis Grevenstein: > 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. > > 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. also (linux-loesung): dvdbackup -p -M -i /dev/sr0 -o /wos/halt/hin/soll das reichte ansich schon, man kann aber auch ein *.iso draus machen: mkisofs -dvd-video -udf -o /wies/halt/hernach/heissen/soll.iso /wos/halt/ist/<name_des_von_dvdbackup_erzeugten_ordners> hat fuer mich funktioniert. dauert je nach dem ~20 min. die ergebnisse sind vlc und smplayer-kompatibel, unter windows womoeglich stress mit css. [...] > 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. ;-) > > Ｂｙｅ／ > ／Ｋａｙ gutes gelingen, -tom
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2024-07-20 22:31 +0200 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <v7h6j8$j0f$5@news.bawue.net> |
| In reply to | #45329 |
On 7/20/24 22:23, tom nossen wrote: > Am 13.01.24 um 21:35 schrieb Dennis Grevenstein: >> 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. >> >> 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. > > also (linux-loesung): > > dvdbackup -p -M -i /dev/sr0 -o /wos/halt/hin/soll > > das reichte ansich schon, man kann aber auch ein *.iso draus machen: > > mkisofs -dvd-video -udf -o /wies/halt/hernach/heissen/soll.iso > /wos/halt/ist/<name_des_von_dvdbackup_erzeugten_ordners> > > hat fuer mich funktioniert. dauert je nach dem ~20 min. die ergebnisse > sind vlc und smplayer-kompatibel, unter windows womoeglich stress mit css. > > [...] Und wenn man einen VIDEO_TS folder hat und vlc, einfach bei vlc diesen Folder zum Abspielen angeben, dann läuft das normalerweise. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | tom nossen <news@nossen.org> |
|---|---|
| Date | 2024-07-20 22:50 +0200 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <v7h7tr$3meqc$2@dont-email.me> |
| In reply to | #45330 |
Am 20.07.24 um 22:31 schrieb Gerrit Heitsch: > On 7/20/24 22:23, tom nossen wrote: >> Am 13.01.24 um 21:35 schrieb Dennis Grevenstein: >>> 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. >>> >>> 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. >> >> also (linux-loesung): >> >> dvdbackup -p -M -i /dev/sr0 -o /wos/halt/hin/soll >> >> das reichte ansich schon, man kann aber auch ein *.iso draus machen: >> >> mkisofs -dvd-video -udf -o /wies/halt/hernach/heissen/soll.iso >> /wos/halt/ist/<name_des_von_dvdbackup_erzeugten_ordners> >> >> hat fuer mich funktioniert. dauert je nach dem ~20 min. die ergebnisse >> sind vlc und smplayer-kompatibel, unter windows womoeglich stress mit >> css. >> >> [...] > > Und wenn man einen VIDEO_TS folder hat und vlc, einfach bei vlc diesen > Folder zum Abspielen angeben, dann läuft das normalerweise. > > > Gerrit das stimmt, aber mit VIDEO_TS hat man halt mehrere ordner und dateien. bei vielen gesicherten dvds oder mehrteiligen boxen kann es leicht zum durcheinander kommen. deswegen habe ich die meinigen wieder zu einem iso zusammengefuehrt -- mkisofs war vom zeitaufwand her nicht einmal eine dreingabe. -tom
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2024-07-21 08:18 +0200 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <v7i90g$g5r$2@news.bawue.net> |
| In reply to | #45333 |
On 7/20/24 22:50, tom nossen wrote: > Am 20.07.24 um 22:31 schrieb Gerrit Heitsch: >> On 7/20/24 22:23, tom nossen wrote: >>> Am 13.01.24 um 21:35 schrieb Dennis Grevenstein: >>>> 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. >>>> >>>> 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. >>> >>> also (linux-loesung): >>> >>> dvdbackup -p -M -i /dev/sr0 -o /wos/halt/hin/soll >>> >>> das reichte ansich schon, man kann aber auch ein *.iso draus machen: >>> >>> mkisofs -dvd-video -udf -o /wies/halt/hernach/heissen/soll.iso >>> /wos/halt/ist/<name_des_von_dvdbackup_erzeugten_ordners> >>> >>> hat fuer mich funktioniert. dauert je nach dem ~20 min. die >>> ergebnisse sind vlc und smplayer-kompatibel, unter windows womoeglich >>> stress mit css. >>> >>> [...] >> >> Und wenn man einen VIDEO_TS folder hat und vlc, einfach bei vlc diesen >> Folder zum Abspielen angeben, dann läuft das normalerweise. >> >> >> Gerrit > > das stimmt, aber mit VIDEO_TS hat man halt mehrere ordner und dateien. > bei vielen gesicherten dvds oder mehrteiligen boxen kann es leicht zum > durcheinander kommen. Ich hab deshalb die VIDEO_TS Ordner in jeweils einem Ordner der den Namen der DVD trägt von dem sie stammen. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-01-15 21:14 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <l0li0eFqh5sU5@mid.individual.net> |
| In reply to | #43276 |
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. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2024-01-13 21:06 +0000 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <unuu0p$hegf$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #43247 |
Mahlzeit! Marcel Mueller <news.5.maazl@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
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2024-01-14 17:57 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <uo13qk$3g4ml$2@gwaiyur.mb-net.net> |
| In reply to | #43336 |
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
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2024-01-14 18:41 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <l0ikmfF5e07U1@mid.individual.net> |
| In reply to | #43351 |
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
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-01-14 20:31 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <1epd7k-m35.ln1@news.martinen.de> |
| In reply to | #43352 |
Am 14.01.24 um 18:41 schrieb 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?
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. ??? ;)
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2024-01-14 21:47 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <uo1h9s$3h2j3$1@gwaiyur.mb-net.net> |
| In reply to | #43352 |
Am 14.01.24 um 18:41 schrieb 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? 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
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-01-14 22:05 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <1uud7k-m35.ln1@news.martinen.de> |
| In reply to | #43358 |
Am 14.01.24 um 21:47 schrieb Marcel Mueller:
> Am 14.01.24 um 18:41 schrieb 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?
>
> 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.
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 ...!
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2024-01-15 09:25 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <l0k8fcFgs7kU1@mid.individual.net> |
| In reply to | #43358 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-01-15 19:00 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <slrnuqasl4.8f09.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #43358 |
On 2024-01-14 20:47, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> Am 14.01.24 um 18:41 schrieb 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?
>
> 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.
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
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2024-01-15 23:31 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <uo4bnk$3qala$3@gwaiyur.mb-net.net> |
| In reply to | #43375 |
Am 15.01.24 um 19:00 schrieb Peter J. Holzer: > On 2024-01-14 20:47, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote: >> 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. > > 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). 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
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-01-17 11:54 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <l0ppujFljtvU4@mid.individual.net> |
| In reply to | #43358 |
Marcel Mueller, 2024-01-14 21:47: > Am 14.01.24 um 18:41 schrieb 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? > > 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. Auch mit "für das Zugriffsmuster geeigneten Datenstrukturen" kann man langsamen Code produzieren, wenn das Zugriffsmuster selbst das Problem ist. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-01-14 19:28 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <slrnuq89tj.3pp0.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #43351 |
On 2024-01-14 16:57, Marcel Mueller <news.5.maazl@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
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2024-01-14 21:52 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <uo1hit$3h2j3$2@gwaiyur.mb-net.net> |
| In reply to | #43353 |
Am 14.01.24 um 19:28 schrieb Peter J. Holzer: > On 2024-01-14 16:57, Marcel Mueller <news.5.maazl@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
[toc] | [prev] | [next] | [standalone]
| From | Christian Garbs <mitch@cgarbs.de> |
|---|---|
| Date | 2024-01-14 21:36 +0000 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <uo1k5j$kgf7$1@yggdrasil.dn.cgarbs.de> |
| In reply to | #43351 |
Mahlzeit! Marcel Mueller <news.5.maazl@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?
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2024-01-15 23:54 +0100 |
| Subject | Re: Prozessorleistung einst und jetzt |
| Message-ID | <uo4d3k$3qala$4@gwaiyur.mb-net.net> |
| In reply to | #43362 |
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
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web