Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.security.misc > #32928 > unrolled thread
| Started by | Philipp Wurzer <phwurzer@gmail.com> |
|---|---|
| First post | 2020-11-06 02:42 -0800 |
| Last post | 2020-11-24 07:40 +0000 |
| Articles | 20 on this page of 233 — 24 participants |
Back to article view | Back to de.comp.security.misc
Verträgliche Sonderzeichen Philipp Wurzer <phwurzer@gmail.com> - 2020-11-06 02:42 -0800
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-06 18:06 +0100
Re: Verträgliche Sonderzeichen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-11-06 18:26 +0100
Re: Verträgliche Sonderzeichen christian_dcsm-ENTF@soemtron.de (Christian @Soemtron) - 2020-11-09 15:01 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-09 16:08 +0100
Re: Verträgliche Sonderzeichen Herrand Petrowitsch <herrands@t-online.de> - 2020-11-09 17:05 +0100
Re: Verträgliche Sonderzeichen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-11-09 19:39 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-06 18:42 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-07 09:50 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-07 10:41 +0000
Re: Verträgliche Sonderzeichen Paul Muster <exp-311220@news.muster.net> - 2020-11-07 18:15 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-09 01:47 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-09 01:49 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-09 02:36 +0000
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-09 13:16 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-08 22:39 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-09 02:40 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-10 13:53 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-10 17:44 +0100
Re: Verträgliche Sonderzeichen Franklin Schiftan <fraschi_usenet@arcor.de> - 2020-11-10 18:06 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-14 12:42 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-14 16:16 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-14 18:28 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-14 21:35 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-15 09:30 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-15 19:40 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-16 09:10 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-16 14:06 +0100
Re: Verträgliche Sonderzeichen Rupert Haselbeck <mein-rest-muell@gmx.de> - 2020-11-14 13:10 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-14 15:55 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-15 14:08 +0100
Re: Verträgliche Sonderzeichen Ulf Volmer <u.volmer@u-v.de> - 2020-11-15 15:07 +0100
Re: Verträgliche Sonderzeichen Herrand Petrowitsch <herrands@t-online.de> - 2020-11-15 15:32 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-15 19:43 +0000
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-16 08:19 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-16 14:24 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-16 16:26 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-16 15:54 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-16 18:01 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-16 17:48 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-16 19:17 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-16 19:52 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-17 10:47 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-17 11:41 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-17 14:02 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-16 19:05 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-16 19:05 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-17 07:08 +0100
Re: Verträgliche Sonderzeichen Jens Hektor <hektor@rz.rwth-aachen.de> - 2020-11-17 11:26 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-17 11:42 +0000
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-17 14:02 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-18 17:58 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-18 19:57 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-19 01:23 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-19 08:07 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-19 12:32 +0000
Re: Verträgliche Sonderzeichen Rupert Haselbeck <mein-rest-muell@gmx.de> - 2020-11-19 16:40 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-19 17:39 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-19 19:57 +0000
Re: Verträgliche Sonderzeichen Sebastian Wolf <invalid@invalid.net> - 2020-11-19 21:50 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-20 08:38 +0100
Re: Verträgliche Sonderzeichen Jens Hektor <hektor@rz.rwth-aachen.de> - 2020-11-20 10:36 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-20 11:04 +0100
Re: Verträgliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-20 11:06 +0000
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-20 12:49 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-19 10:54 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-19 12:27 +0100
Re: Verträgliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-19 13:18 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-19 17:39 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-19 16:57 +0100
Re: Verträgliche Sonderzeichen Rupert Haselbeck <mein-rest-muell@gmx.de> - 2020-11-16 10:50 +0100
Re: Verträgliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-16 16:25 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-16 19:06 +0100
Re: Verträgliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-16 14:07 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-11-06 19:58 +0100
Re: Vertraegliche Sonderzeichen Sven Hartge <sh-20B@svenhartge.de> - 2020-11-07 11:11 +0100
Re: Verträgliche Sonderzeichen Herrand Petrowitsch <herrands@t-online.de> - 2020-11-06 19:10 +0100
Re: Verträgliche Sonderzeichen Stefan Claas <usenet@ctemplar.com> - 2020-11-06 19:38 +0000
Re: Verträgliche Sonderzeichen Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-11-06 17:56 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-11-21 18:42 +0100
Re: Vertraegliche Sonderzeichen Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-11-22 19:58 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-23 07:58 +0100
Re: Vertraegliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-23 08:16 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-11-23 10:18 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-23 09:55 +0000
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-24 11:10 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-23 10:30 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-23 10:07 +0000
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-23 11:46 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-24 11:10 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-24 14:10 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-24 21:34 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-24 22:35 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-25 09:58 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-25 13:42 +0100
Re: Vertraegliche Sonderzeichen Takvorian <tak-us@gmx.de> - 2020-11-26 14:57 +0100
Re: Vertraegliche Sonderzeichen Rupert Haselbeck <mein-rest-muell@gmx.de> - 2020-11-25 00:50 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-24 11:15 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-24 14:12 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-24 13:58 +0000
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-24 16:58 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-24 17:09 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-25 11:35 +0000
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-25 13:47 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-25 19:49 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-25 20:02 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-25 23:59 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-26 10:45 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-29 22:47 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-11-30 12:35 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-03 02:58 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-06 22:00 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-11 07:21 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-12 21:02 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-13 01:26 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-13 07:10 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-13 12:46 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-13 14:12 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-12-13 16:42 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-13 16:47 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-12-13 17:21 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-23 19:46 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 09:07 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-26 19:58 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 21:07 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-27 01:11 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 05:23 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-27 15:22 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 15:31 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-28 13:45 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-12-14 00:43 +0000
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-23 19:51 +0100
Re: Vertraegliche Sonderzeichen Stefan Reuther <stefan.news@arcor.de> - 2020-12-24 09:05 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 13:05 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-12-25 00:02 +0000
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 10:08 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-26 20:05 +0100
Re: Vertraegliche Sonderzeichen Stefan Reuther <stefan.news@arcor.de> - 2020-12-25 19:56 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 20:47 +0100
Re: Vertraegliche Sonderzeichen Stefan Reuther <stefan.news@arcor.de> - 2020-12-26 10:22 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 10:53 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 13:04 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-26 20:07 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 21:10 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-27 01:26 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 05:26 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-27 15:28 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 15:34 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-28 13:58 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 16:40 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-28 16:57 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 17:07 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 17:38 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-28 19:15 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 19:24 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 02:11 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 09:35 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 13:50 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-28 19:13 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 19:23 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 02:17 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 09:32 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 19:32 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 02:27 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 09:29 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-12-29 10:43 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 13:55 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 15:03 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-30 18:27 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-30 18:49 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-30 21:55 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-31 06:34 +0100
Re: Vertraegliche Sonderzeichen Stefan Reuther <stefan.news@arcor.de> - 2020-12-29 08:37 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 14:00 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 14:14 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 14:26 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 15:07 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 21:08 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 21:18 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 21:19 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-28 21:39 +0100
Re: Vertraegliche Sonderzeichen Thomas Noll <-_tn_-@web.de> - 2020-12-29 15:27 +0000
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 17:34 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-30 18:29 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-30 18:56 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-30 22:11 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 19:41 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-30 18:35 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-30 19:05 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-12-30 19:25 +0000
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-30 20:30 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-30 22:14 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-31 03:27 +0100
OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) Thomas Noll <-_tn_-@web.de> - 2021-01-01 14:46 +0000
Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) Bonita Montero <Bonita.Montero@gmail.com> - 2021-01-01 16:46 +0100
Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) Bonita Montero <Bonita.Montero@gmail.com> - 2021-01-01 17:36 +0100
Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) Bonita Montero <Bonita.Montero@gmail.com> - 2021-01-01 18:41 +0100
Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) Arno Welzel <usenet@arnowelzel.de> - 2021-01-02 05:00 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2021-01-02 04:53 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 02:41 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 09:30 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-29 14:01 +0100
Re: Vertraegliche Sonderzeichen Stefan Reuther <stefan.news@arcor.de> - 2020-12-27 12:04 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 13:54 +0100
Re: Vertraegliche Sonderzeichen Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 15:00 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-26 20:03 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-26 11:58 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-26 19:32 +0100
Re: Vertraegliche Sonderzeichen Stefan Reuther <stefan.news@arcor.de> - 2020-11-24 18:32 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-24 18:42 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-25 19:46 +0000
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-25 20:53 +0100
Re: Vertraegliche Sonderzeichen Florian Weimer <fw@deneb.enyo.de> - 2020-11-29 12:14 +0100
Re: Vertraegliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-29 12:30 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-29 22:49 +0100
Re: Vertraegliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-30 11:04 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-03 02:59 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-12-03 13:34 +0000
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-06 19:07 +0100
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-12-07 03:22 +0000
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-11 07:23 +0100
Re: Vertraegliche Sonderzeichen Stefan Reuther <stefan.news@arcor.de> - 2020-12-03 17:44 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-12-06 19:09 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-29 13:53 +0100
Re: Vertraegliche Sonderzeichen Arno Welzel <usenet@arnowelzel.de> - 2020-11-24 11:07 +0100
Re: Vertraegliche Sonderzeichen Christian Hanné <the.hanne@gmail.com> - 2020-11-24 14:13 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-11-23 10:16 +0100
Re: Vertraegliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-23 14:10 +0100
Re: Vertraegliche Sonderzeichen Arne Johannessen <arne-9544@thaw.de> - 2020-11-23 17:04 +0100
Re: Vertraegliche Sonderzeichen Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-11-23 18:24 +0100
Re: Vertraegliche Sonderzeichen Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-11-23 20:07 +0100
Re: Vertraegliche Sonderzeichen Christian Weisgerber <naddy@mips.inka.de> - 2020-11-23 23:44 +0000
Re: Vertraegliche Sonderzeichen Juergen Ilse <news@usenet-verwaltung.de> - 2020-11-24 07:40 +0000
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-28 21:39 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsdfqe$5u7$1@dont-email.me> |
| In reply to | #33187 |
> for( unsigned c = 32; c; --c )
> stringBuild[c] = uidLetters( randomGenerator );
Kleiner Fehler:
for( unsigned c = 0; c != 32; ++c )
stringBuild[c] = uidLetters( randomGenerator );
Timing bleibt aber gleich.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Noll <-_tn_-@web.de> |
|---|---|
| Date | 2020-12-29 15:27 +0000 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsfhsg$nup$1@news.dns-netz.com> |
| In reply to | #33190 |
Am Mon, 28 Dec 2020 21:39:43 +0100 schrieb Bonita Montero: >> for( unsigned c = 32; c; --c ) >> stringBuild[c] = uidLetters( randomGenerator ); > > Kleiner Fehler: > > for( unsigned c = 0; c != 32; ++c ) > stringBuild[c] = uidLetters( randomGenerator ); > > Timing bleibt aber gleich. Das glaube ich nicht. 10 Millionen leere Strings (0-Terminated an Position 0) gehen doch deutlich schneller zu sortieren als 10 Millionen zufälliger Strings der Länge 32. Die Zeiten bei mir: openjdk 11: 5,6 / 8,3 Sekunden g++ 8.3.0, -O3 6,0 / 8,4 Sekunden Ohne die "kleine Korrektur" waren es 5,3 / 0,55 Sekunden. Beides mit Single-Thread sort. Parallel gibt der Compiler bzw. die Library nicht her.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-29 17:34 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsflrg$dsc$1@dont-email.me> |
| In reply to | #33209 |
> Das glaube ich nicht. 10 Millionen leere Strings (0-Terminated an Position 0)
^^^^^^^^^^^^^^^^^^^^
Ne, das hängt davon ab, was da gerade an Stelle Null im Stack steht,
eine Null Default-Initialisierung kennt C++ aus Performance-Gründen
nicht. Bei mir stand da halt wiederholbarerweise was anderes als Null.
> gehen doch deutlich schneller zu sortieren als 10 Millionen zufälliger Strings
> der Länge 32.
>
> Die Zeiten bei mir:
>
> openjdk 11:
> 5,6 / 8,3 Sekunden
>
> g++ 8.3.0, -O3
> 6,0 / 8,4 Sekunden
>
> Ohne die "kleine Korrektur" waren es
> 5,3 / 0,55 Sekunden.
>
> Beides mit Single-Thread sort. Parallel gibt der Compiler bzw. die Library
> nicht her.
Tja, dann ist das nicht vergleichbar.
Ich hab das mit -std=c++17 kompiliert und auf einem
Threadripper 3990X laufen lassen.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-12-30 18:29 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <i53rnpFl32eU2@mid.individual.net> |
| In reply to | #33210 |
Bonita Montero: >> Das glaube ich nicht. 10 Millionen leere Strings (0-Terminated an Position 0) > ^^^^^^^^^^^^^^^^^^^^ > Ne, das hängt davon ab, was da gerade an Stelle Null im Stack steht, > eine Null Default-Initialisierung kennt C++ aus Performance-Gründen > nicht. Bei mir stand da halt wiederholbarerweise was anderes als Null. > >> gehen doch deutlich schneller zu sortieren als 10 Millionen zufälliger Strings >> der Länge 32. >> >> Die Zeiten bei mir: >> >> openjdk 11: >> 5,6 / 8,3 Sekunden >> >> g++ 8.3.0, -O3 >> 6,0 / 8,4 Sekunden >> >> Ohne die "kleine Korrektur" waren es >> 5,3 / 0,55 Sekunden. >> >> Beides mit Single-Thread sort. Parallel gibt der Compiler bzw. die Library >> nicht her. > > Tja, dann ist das nicht vergleichbar. Doch, *nur* dann ist es vergleichbar. Der Unterschied ist nämlich dann nicht "Java vs. C++" sondern "single threaded vs. multi threaded". -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-30 18:56 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsif17$s7u$1@dont-email.me> |
| In reply to | #33213 |
> Doch, *nur* dann ist es vergleichbar. Der Unterschied ist nämlich dann > nicht "Java vs. C++" sondern "single threaded vs. multi threaded". Ich hab hier noch ein Update gegeben, wo selbst der single-threaded Algorithmus schneller ist. Single-threaded ist das Sortieren so 61% schneller als in Java. Das liegt daran, dass ich nicht hier wie bei Java ein Array von Referenzen habe, das ich sortiere, sondern ein Array von Objekten. Das ist die von mir besagte Schwäche von Java, dass man keine Arrays von Objekten haben kann die durchgehend im linearen Speicher liegen. Das kann in anderen Fällen noch viel krasser ausfallen wenn diese Objekte dann eine tiefe Scachtelung haben, während eingebettete Objekte in C++ im selben Speicherblock liegen wie das einbettende. Bei den 128 Threads auf meiner CPU sieht Java natürlich nur die Rücklichter. Aber ansich könnten die ja mal Collections.sort() auch mal parallelisieren.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-12-30 22:11 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <i548n4Fnj6mU1@mid.individual.net> |
| In reply to | #33216 |
Bonita Montero: >> Doch, *nur* dann ist es vergleichbar. Der Unterschied ist nämlich dann >> nicht "Java vs. C++" sondern "single threaded vs. multi threaded". > > Ich hab hier noch ein Update gegeben, wo selbst der single-threaded > Algorithmus schneller ist. Single-threaded ist das Sortieren so 61% > schneller als in Java. Das liegt daran, dass ich nicht hier wie bei > Java ein Array von Referenzen habe, das ich sortiere, sondern ein > Array von Objekten. Das ist die von mir besagte Schwäche von Java, > dass man keine Arrays von Objekten haben kann die durchgehend im > linearen Speicher liegen. Das kann in anderen Fällen noch viel > krasser ausfallen wenn diese Objekte dann eine tiefe Scachtelung > haben, während eingebettete Objekte in C++ im selben Speicherblock > liegen wie das einbettende. Das ist allerdings eher ein Problem des Designs von Java und hat nichts damit zu tun, ob es compliert als nativer Code läuft oder nicht. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-29 19:41 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsft8s$8kp$1@dont-email.me> |
| In reply to | #33209 |
Ich hab ja den Vetor mit unique_ptr-Objekten gehabt. Ich dachte
mir, das geht schneller weil das ein einfacher Pointer ist, der
da zu swappen ist. Damit entspricht die Datenstruktur ziemlich
dem, was in Java der Fall ist, denn Java hat ja wie ich anderswo
schon erwähnt habe das gravierende Manko, dass es kein Array von
Objekten kennt die fortlaufend im Speicher liegen.
Andererseits ist es so, dass alle Vergleich -Operationen hinter
diesem Pointer serialisiert in der CPU ablaufen, d.h. die Out-of
-Order-Ausführung nicht so zuschlagen kann. Inwieweit die schnel-
leren Swaps der Pointer gegenüber den Swaps oder den String-Ob-
jekten jetzt eine Rolle spielten war für mich nicht ganz klar;
also habe ich den Source mal modifiziert und direkt einen Vektor
von String-Objekten genommen:
#include <iostream>
#include <cstdlib>
#include <random>
#include <vector>
#include <string>
#include <memory>
#include <chrono>
#include <algorithm>
#include <execution>
using namespace std;
using namespace chrono;
using namespace execution;
//#define USE_CHAR
int main( int argc, char **argv )
{
#if !defined(USE_CHAR)
using ch = wchar_t;
#else
using ch = char;
#endif
using str = basic_string<ch>;
using hrc_tp = time_point<high_resolution_clock>;
if( argc < 2 )
return EXIT_FAILURE;
unsigned nLines = atoi( argv[1] );
vector<str> randomStrings;
mt19937 randomGenerator;
uniform_int_distribution<unsigned> uidLetters( 'a', 'z' );
ch stringBuild[32 + 1];
stringBuild[32] = 0;
randomStrings.reserve( nLines );
hrc_tp start = high_resolution_clock::now();
for( unsigned i = nLines; i; --i )
{
for( size_t c = 0; c != 32; ++c )
stringBuild[c] = uidLetters( randomGenerator );
randomStrings.emplace_back( stringBuild );
}
double secs = (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() / 1.0e9;
cout << "generating table: " << secs << "s" << endl;
start = high_resolution_clock::now();
sort( parallel_policy(), randomStrings.begin(), randomStrings.end(),
[]( str &left, str &right )
{
return left < right;
} );
secs = (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() / 1.0e9;
cout << "sorting table: " << secs << "s" << endl;
}
Dadurch habe ich nochmal einen Performance-SChub von 15% beim Gene-
rieren der Tabelle gehabt, und einen von 73% beim Sortieren. Da sieht
man eben den Unterschied zu Java, denn das erlaubt keine solchen im
Speicher fortlaufenden Datenstrukturen.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-12-30 18:35 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <i53s3eFl6g5U1@mid.individual.net> |
| In reply to | #33211 |
Bonita Montero: > Ich hab ja den Vetor mit unique_ptr-Objekten gehabt. Ich dachte > mir, das geht schneller weil das ein einfacher Pointer ist, der > da zu swappen ist. Damit entspricht die Datenstruktur ziemlich > dem, was in Java der Fall ist, denn Java hat ja wie ich anderswo > schon erwähnt habe das gravierende Manko, dass es kein Array von > Objekten kennt die fortlaufend im Speicher liegen. > Andererseits ist es so, dass alle Vergleich -Operationen hinter > diesem Pointer serialisiert in der CPU ablaufen, d.h. die Out-of > -Order-Ausführung nicht so zuschlagen kann. Inwieweit die schnel- > leren Swaps der Pointer gegenüber den Swaps oder den String-Ob- > jekten jetzt eine Rolle spielten war für mich nicht ganz klar; > also habe ich den Source mal modifiziert und direkt einen Vektor > von String-Objekten genommen: [...] > Dadurch habe ich nochmal einen Performance-SChub von 15% beim Gene- > rieren der Tabelle gehabt, und einen von 73% beim Sortieren. Da sieht > man eben den Unterschied zu Java, denn das erlaubt keine solchen im > Speicher fortlaufenden Datenstrukturen. Sicher. Dennoch ist sind 15% oder 73% zwar durchaus relevant, aber nicht so extrem, dass man von dutzendfacher oder gar hundertfacher Performance sprechen kann. Da geht dann eher in die von mir angedeuteten Unterschiede in der Größenordnung von Faktor 2-3. Und zum Beispiel "Mediathekview": Wenn der Aufbau einer Tabelle mit Java bei Dir 30 Sekunden dauert, wäre die selbe Anwendung mit C++ immer noch bei 8-9 Sekunden. Ja, das wäre schon ein Fortschritt - aber eben immer noch inakzeptabel langsam. Niemand will beim Anklicken einer Tabellenspalte erstmal fast 10 Sekunden warten, bis die Ansicht neu sortiert ist. Daher sehe ich hier das Problem nicht so sehr in der Wahl von Java statt C++ als viel mehr eine generell ungeeignete Architektur der Anwendung für diesen Zweck. Für die Verwaltung von über 400.000 Einträgen in einer Tabelle nimmt man Datenbanken mit Index und nicht JSON-Dateien, die man einlesen und im Speicher sortieren muss. Wenn das Herunterladen der neuen Sendungsdaten einmalig 10-30 Sekunden dauert, um den Index neu aufzubauen, ist das viel eher zu verschmerzen, als wenn man *jedesmal* so lange warten muss, selbst wenn man nur die Sortieurng anders haben will. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-30 19:05 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsifi1$15v$1@dont-email.me> |
| In reply to | #33214 |
> Sicher. Dennoch ist sind 15% oder 73% zwar durchaus relevant, aber nicht > so extrem, dass man von dutzendfacher oder gar hundertfacher Performance > sprechen kann. ... Ich habe eine 64-Kern-CPU mit 128 Threads, da wird std::sort auf alle Threads ausgerollt (std::sort erkennt sogar unter Windows meine Prozessor-Gruppen und kann sich breiter ausrollen als der Scheduler eigentlich kann) und ist entsprechend schneller. Die 73% kommen nochmal obendrauf, dass die Performance bei meinem Beispiel parallelisiert ca. 226 mal schneller ist. > Wenn der Aufbau einer Tabelle mit Java bei Dir 30 Sekunden dauert, wäre > die selbe Anwendung mit C++ immer noch bei 8-9 Sekunden. Grundsätzlich muss ein Sortieren im reinen Vergleichen und Vertauschen von Referenzen in einem Index stattfinden. Das sollte in C++ eine Grö- ßenordnung schneller gehen > Niemand will beim Anklicken einer Tabellenspalte erstmal fast 10 > Sekunden warten, bis die Ansicht neu sortiert ist. Daher sehe ich hier > das Problem nicht so sehr in der Wahl von Java statt C++ als viel mehr > eine generell ungeeignete Architektur der Anwendung für diesen Zweck. Kann sein, dass das Vergleichs-Interface ineffizient bedient wird. > Für die Verwaltung von über 400.000 Einträgen in einer Tabelle nimmt man > Datenbanken mit Index und nicht JSON-Dateien, die man einlesen und im > Speicher sortieren muss. ... Sehe ich nicht so. Wenn die Daten nicht den Programmstart überleben müssen und nicht so groß sind, dass sie den Adressraum sprengen, dann kann man das auch locker im RAM machen.
[toc] | [prev] | [next] | [standalone]
| From | Juergen Ilse <news@usenet-verwaltung.de> |
|---|---|
| Date | 2020-12-30 19:25 +0000 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <5fecd444$0$32756$7b62cf90@news1.net.de> |
| In reply to | #33217 |
Hallo, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Sicher. Dennoch ist sind 15% oder 73% zwar durchaus relevant, aber nicht >> so extrem, dass man von dutzendfacher oder gar hundertfacher Performance >> sprechen kann. ... > > Ich habe eine 64-Kern-CPU mit 128 Threads, Ich wuerde schaetzen, dass (abgesehen von notorischen Computer-Spielern) bei mindestens 80-90% der Heimanwender nicht so ein Monster zu finden ist. > Die 73% kommen nochmal obendrauf, dass die Performance bei meinem > Beispiel parallelisiert ca. 226 mal schneller ist. Bei den meisten Anwendungen erhaelt man durch Parallelisierung keine Steigerung, die linear mit der Anzahl der CPUs steigen wuerde. Der "Verwaltungs-Overhead" wird mit steigender Anzahl der CPUs naeemlich auch imer hoeher. Es ist auch zweitrangig, um wieviel langsamer Java gegenueber C++ ist, relevant ist, ob die Anwendung (egal in welcher Sprache geschrieben) ausreichend performant ist. Und bei vielen Anwendungen genuegt eine evt. geringere Performance. Tschuess, Juergen Ilse (juergen@usenet-verwaltung.de)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-30 20:30 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsikgb$7et$1@dont-email.me> |
| In reply to | #33218 |
> Bei den meisten Anwendungen erhaelt man durch Parallelisierung keine > Steigerung, die linear mit der Anzahl der CPUs steigen wuerde. In dem Fall sogar gerinfügig super-linear weil Cache-Inhalte von über- geordneten Threads der Quicksort-Rekursion vorgewärmt im Cache liegen. > Der "Verwaltungs-Overhead" wird mit steigender Anzahl der CPUs naeemlich > auch imer hoeher. Bei Quicksort ist der minimal. Und da ich stochastisch gleichmäßig gut verteilte Strings generiert habe kommt es nicht vor, dass Quicksort hier degeneriert und seinen Rekursions-Baum nicht symmetrisch in Threads ver- teilt.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-12-30 22:14 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <i548u4FnkeiU1@mid.individual.net> |
| In reply to | #33217 |
Bonita Montero: >> Sicher. Dennoch ist sind 15% oder 73% zwar durchaus relevant, aber nicht >> so extrem, dass man von dutzendfacher oder gar hundertfacher Performance >> sprechen kann. ... > > Ich habe eine 64-Kern-CPU mit 128 Threads, da wird std::sort auf > alle Threads ausgerollt (std::sort erkennt sogar unter Windows > meine Prozessor-Gruppen und kann sich breiter ausrollen als der > Scheduler eigentlich kann) und ist entsprechend schneller. Die > 73% kommen nochmal obendrauf, dass die Performance bei meinem > Beispiel parallelisiert ca. 226 mal schneller ist. Wie gesagt: single threaded vs. multi threaded ist kein sinnvoller Vergleich, wenn es nur die absoluten Unterschiede wegen der Sprache ans ich geht. [...] >> Für die Verwaltung von über 400.000 Einträgen in einer Tabelle nimmt man >> Datenbanken mit Index und nicht JSON-Dateien, die man einlesen und im >> Speicher sortieren muss. ... > > Sehe ich nicht so. Wenn die Daten nicht den Programmstart überleben > müssen und nicht so groß sind, dass sie den Adressraum sprengen, dann > kann man das auch locker im RAM machen. Ein Index, der die Sortierung effizient ermögliocht, sollte den Programmstart aber überleben, damit man ihn eben nicht jedesmal neu erzeugen muss. Zu Zeiten, als CPU noch nicht mehrere GB Daten im RAM herumgeschubst haben, hat man über sowas noch nachgedacht. Nur weil moderne CPUs sowas prinzipiell können, muss man ja nicht sinnlos Ressourcen verbraten. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-31 03:27 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <rsjcto$56a$1@dont-email.me> |
| In reply to | #33222 |
Am 30.12.2020 um 22:14 schrieb Arno Welzel: >>> Sicher. Dennoch ist sind 15% oder 73% zwar durchaus relevant, aber nicht >>> so extrem, dass man von dutzendfacher oder gar hundertfacher Performance >>> sprechen kann. ... >> Ich habe eine 64-Kern-CPU mit 128 Threads, da wird std::sort auf >> alle Threads ausgerollt (std::sort erkennt sogar unter Windows >> meine Prozessor-Gruppen und kann sich breiter ausrollen als der >> Scheduler eigentlich kann) und ist entsprechend schneller. Die >> 73% kommen nochmal obendrauf, dass die Performance bei meinem >> Beispiel parallelisiert ca. 226 mal schneller ist. > Wie gesagt: single threaded vs. multi threaded ist kein sinnvoller > Vergleich, wenn es nur die absoluten Unterschiede wegen der Sprache > ans ich geht. Würd ich nicht sagen, denn der Java-Entwickler nimmt die Sprachmittel die er zur Verfügung hat und der C++-Entwickler ebenso. Dass jemand sein Quicksort selbst implementiert, das gar parallel, ist sicher nicht die Regel. >>> Für die Verwaltung von über 400.000 Einträgen in einer Tabelle nimmt man >>> Datenbanken mit Index und nicht JSON-Dateien, die man einlesen und im >>> Speicher sortieren muss. ... >> Sehe ich nicht so. Wenn die Daten nicht den Programmstart überleben >> müssen und nicht so groß sind, dass sie den Adressraum sprengen, dann >> kann man das auch locker im RAM machen. > Ein Index, der die Sortierung effizient ermögliocht, sollte den > Programmstart aber überleben, ... Das sehen die Leute von MediathekView nicht so, und ich kann das verstehen.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Noll <-_tn_-@web.de> |
|---|---|
| Date | 2021-01-01 14:46 +0000 |
| Subject | OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) |
| Message-ID | <rsnckv$t2$1@news.dns-netz.com> |
| In reply to | #33223 |
Am Thu, 31 Dec 2020 03:27:05 +0100 schrieb Bonita Montero:
> Am 30.12.2020 um 22:14 schrieb Arno Welzel:
>>>> Sicher. Dennoch ist sind 15% oder 73% zwar durchaus relevant, aber nicht
>>>> so extrem, dass man von dutzendfacher oder gar hundertfacher Performance
>>>> sprechen kann. ...
>
>>> Ich habe eine 64-Kern-CPU mit 128 Threads, da wird std::sort auf
>>> alle Threads ausgerollt (std::sort erkennt sogar unter Windows
>>> meine Prozessor-Gruppen und kann sich breiter ausrollen als der
>>> Scheduler eigentlich kann) und ist entsprechend schneller. Die
>>> 73% kommen nochmal obendrauf, dass die Performance bei meinem
>>> Beispiel parallelisiert ca. 226 mal schneller ist.
>
>> Wie gesagt: single threaded vs. multi threaded ist kein sinnvoller
>> Vergleich, wenn es nur die absoluten Unterschiede wegen der Sprache
>> ans ich geht.
>
> Würd ich nicht sagen, denn der Java-Entwickler nimmt die Sprachmittel
> die er zur Verfügung hat und der C++-Entwickler ebenso. Dass jemand
> sein Quicksort selbst implementiert, das gar parallel, ist sicher
> nicht die Regel.
Allerdings wissen viele Entwickler nicht, welche Sprachmittel ihnen zur
Verfügung stehen. Hier mal eine Java Variante deines Beispiels, die die
Bordmittel etwas besser ausnutzt:
// snip to
import java.util.Arrays;
import java.util.concurrent.ThreadLocalRandom;
public class RandStringSort2 {
static boolean verbose = true;
public static void main(String[] args) {
int nStrings = Integer.parseInt("100000000");
long start = System.currentTimeMillis();
String[] randomStrings = new String[nStrings];
int[] selectLines = { 0, 1, nStrings / 2, nStrings - 2, nStrings - 1 };
Arrays.parallelSetAll(randomStrings, (dummy) -> {
StringBuffer sb = new StringBuffer();
for (int c = 0; c < 32; ++c) {
sb.append((char) ('a' + ThreadLocalRandom.current().nextInt(26)));
}
return sb.toString();
});
if (verbose) {
for (int i : selectLines) {
System.out.printf("%09d: %s\n", i, randomStrings[i]);
}
}
float secs = (System.currentTimeMillis() - start) / 1.0e3f;
System.out.printf("generating table: %fs\n", secs);
start = System.currentTimeMillis();
Arrays.parallelSort(randomStrings);
secs = (System.currentTimeMillis() - start) / 1.0e3f;
System.out.printf("sorting table: %fs\n", secs);
// round 2
start = System.currentTimeMillis();
Arrays.parallelSort(randomStrings);
secs = (System.currentTimeMillis() - start) / 1.0e3f;
System.out.printf("sorting table 2: %fs\n", secs);
if (verbose) {
for (int i : selectLines) {
System.out.printf("%09d: %s\n", i, randomStrings[i]);
}
}
}
}
// here
Wie lange läuft das auf deinem Rechner?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-01-01 16:46 +0100 |
| Subject | Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) |
| Message-ID | <rsng45$a40$1@dont-email.me> |
| In reply to | #33227 |
> Wie lange läuft das auf deinem Rechner? Das Sortieren ist 81,2 mal schneller; aber immer noch nicht das was man in C++ rausholen kann. Seltsamerweise ist das Swappen von String-Objekten in C++ schneller als das Swappen von Pointern darauf, dass der besagte "lineares Array" -Effekt mit seinem Boost von 73% zuschlägt. Das ist eine Sache die in Java unmöglich ist weil es keine Werttyp-Objekte kennt.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-01-01 17:36 +0100 |
| Subject | Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) |
| Message-ID | <rsnj2f$v1j$1@dont-email.me> |
| In reply to | #33227 |
Hier, nimm das zum Vergleich:
#if defined(_MSC_VER)
#define _HAS_ITERATOR_DEBUGGING 0
#endif
#include <iostream>
#include <cstdlib>
#include <random>
#include <vector>
#include <string>
#include <memory>
#include <chrono>
#include <algorithm>
#include <execution>
#include <functional>
using namespace std;
using namespace chrono;
using namespace execution;
template<typename ItType, typename setter>
void parallelSetAll( ItType begin, ItType end, setter &st )
{
unsigned hc = thread::hardware_concurrency();
hc += !hc;
vector<thread> vt;
vt.reserve( hc );
size_t n = end - begin;
auto fn = [&st]( ItType begin, ItType end )
{
st( begin, end );
};
for( unsigned t = 0; t != hc; ++t )
{
// erst * n, dann / hc und nicht umgekehert wg. Rundungsverlusten
ItType start = begin + t * n / hc,
finish = begin + (t + 1) * n / hc;
vt.emplace_back( bind( fn, start, finish ) );
}
for( thread &thr : vt )
thr.join();
}
int main( int argc, char **argv )
{
#if !defined(USE_CHAR)
using ch = wchar_t;
#else
using ch = char;
#endif
using str = basic_string<ch>;
using hrc_tp = time_point<high_resolution_clock>;
if( argc < 2 )
return EXIT_FAILURE;
using vstr = vector<str>;
using vstrit = vector<str>::iterator;
unsigned nLines = atoi( argv[1] );
vector<str> randomStrings( nLines );
auto setStrRange = []( vstrit begin, vstrit end )
{
vector<str> randomStrings;
mt19937 randomGenerator;
uniform_int_distribution<unsigned> uidLetters( 'a', 'z' );
ch stringBuild[32 + 1];
stringBuild[32] = 0;
for( vstrit s = begin; s != end; ++s )
{
for( size_t c = 32; c-- != 0; )
stringBuild[c] = uidLetters( randomGenerator );
*s = str( stringBuild );
}
};
hrc_tp start = high_resolution_clock::now();
parallelSetAll( randomStrings.begin(), randomStrings.end(), setStrRange );
double secs = (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() / 1.0e9;
cout << "generating table: " << secs << "s" << endl;
start = high_resolution_clock::now();
sort( /* parallel_policy(), */ randomStrings.begin(), randomStrings.end(),
[]( str &left, str &right )
{
return left < right;
} );
secs = (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() / 1.0e9;
cout << "sorting table: " << secs << "s" << endl;
}
Kommt Java nicht hinterher ...
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-01-01 18:41 +0100 |
| Subject | Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) |
| Message-ID | <rsnms0$rrl$1@dont-email.me> |
| In reply to | #33229 |
Ursprüngliche Java-Version von mir:
java -Xmx32g RandStringSort 10000000
generating table: 32,273998s
sorting table: 13,673000s
Neue Version von dir:
java -Xmx32g RandStringSort2
generating table: 0,397463s
sorting table: 0,168386s
Ursprüngliche C++-Version:
RandStringSort 10000000
generating table: 5.68236s
sorting table: 0.104253s
Neue C++-Version:
RandStringSort 10000000
generating table: 0.093153s
sorting table: 0.104291s
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2021-01-02 05:00 +0100 |
| Subject | Re: OT: Java vs. C++ (was: Re: Vertraegliche Sonderzeichen) |
| Message-ID | <i5a9fhFspb9U1@mid.individual.net> |
| In reply to | #33227 |
Thomas Noll: > Am Thu, 31 Dec 2020 03:27:05 +0100 schrieb Bonita Montero: > >> Am 30.12.2020 um 22:14 schrieb Arno Welzel: >>>>> Sicher. Dennoch ist sind 15% oder 73% zwar durchaus relevant, aber nicht >>>>> so extrem, dass man von dutzendfacher oder gar hundertfacher Performance >>>>> sprechen kann. ... >> >>>> Ich habe eine 64-Kern-CPU mit 128 Threads, da wird std::sort auf >>>> alle Threads ausgerollt (std::sort erkennt sogar unter Windows >>>> meine Prozessor-Gruppen und kann sich breiter ausrollen als der >>>> Scheduler eigentlich kann) und ist entsprechend schneller. Die >>>> 73% kommen nochmal obendrauf, dass die Performance bei meinem >>>> Beispiel parallelisiert ca. 226 mal schneller ist. >> >>> Wie gesagt: single threaded vs. multi threaded ist kein sinnvoller >>> Vergleich, wenn es nur die absoluten Unterschiede wegen der Sprache >>> ans ich geht. >> >> Würd ich nicht sagen, denn der Java-Entwickler nimmt die Sprachmittel >> die er zur Verfügung hat und der C++-Entwickler ebenso. Dass jemand >> sein Quicksort selbst implementiert, das gar parallel, ist sicher >> nicht die Regel. > > Allerdings wissen viele Entwickler nicht, welche Sprachmittel ihnen zur > Verfügung stehen. Hier mal eine Java Variante deines Beispiels, die die > Bordmittel etwas besser ausnutzt: > > // snip to > > import java.util.Arrays; > import java.util.concurrent.ThreadLocalRandom; [...] > Wie lange läuft das auf deinem Rechner? Mit 10 Mio. Einträgen läuft das hier gar nicht. Mit 8 Mio. geht es noch, aber ohne erkennbare Vorteile bei der ersten Sortier-Runde: generating table: 3.236000s sorting table: 10.063000s sorting table 2: 0.773000s -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2021-01-02 04:53 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <i5a91nFslubU2@mid.individual.net> |
| In reply to | #33223 |
Bonita Montero: > Am 30.12.2020 um 22:14 schrieb Arno Welzel: [...] >> Ein Index, der die Sortierung effizient ermögliocht, sollte den >> Programmstart aber überleben, ... > > Das sehen die Leute von MediathekView nicht so, und ich kann das > verstehen. Ich nicht. Denn die aktuelle Lösung erfordert eben je nach Umgebung und ausgewählter Spalte zur Sortierung zwischen 15-30 Sekunden Wartezeit bei *jedem* Programmstart. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-12-29 02:41 +0100 |
| Subject | Re: Vertraegliche Sonderzeichen |
| Message-ID | <i4vfq3FpjdaU1@mid.individual.net> |
| In reply to | #33187 |
Bonita Montero: > Hier, mal kleines Beispiel. Generieren von N Strings mit zufälligem > Inhalt, dann sortieren in Java und in C++. Danke - endlich mal was Konkretes. [...] > Java-Timing bei 10.000.000 Strings: > java -Xmx32g RandStringSort 10000000 > generating table: 32,273998s > sorting table: 13,673000s Hier: java -Xmx32g RandStringSort 10000000 generating table: 7.370000s sorting table: 12.018000s Wieso braucht dein System bei "generating table" mehr als drei Mal so lang? > C++-Timing bei ebenso viel Strings: > RandStringSort 10000000 > generating table: 5.68236s > sorting table (1 thread): 0.104253s > > Generieren 5,6 mal schneller. > Sortieren ca. 131 mal schneller. > Noch Fragen ? Nein, wieso? Habe ich irgendwo behauptet, Java wäre genauso schnell wie C++? -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
Back to top | Article view | de.comp.security.misc
csiph-web