Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #79507 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-05-16 18:10 +0200 |
| Last post | 2021-05-18 15:14 -0700 |
| Articles | 20 on this page of 249 — 76 participants |
Back to article view | Back to comp.lang.c++
Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-16 18:10 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-16 10:54 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-16 20:01 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-16 11:29 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 08:20 +0200
Re: Niuce C++14-feature MrSpook_f4zl13qm@8lfoe01ih4ebku.com - 2021-05-17 09:26 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 12:52 +0200
Re: Niuce C++14-feature MrSpook_yMgsa7x5@3ifr32ivepk32ia.org - 2021-05-17 11:29 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 13:42 +0200
Re: Niuce C++14-feature MrSpook_zSl@bw3y07so7dr3go2x.tv - 2021-05-17 13:31 +0000
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-17 19:53 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-18 05:39 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-17 22:33 -0700
Re: Niuce C++14-feature MrSpook_sey@tad.gov.uk - 2021-05-17 07:42 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 10:58 +0000
Re: Niuce C++14-feature MrSpook_vj8xvznaud@d16tgqd.co.uk - 2021-05-17 11:32 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 12:03 +0000
Re: Niuce C++14-feature MrSpook_gT9q@x057vr3tuoe9s_ht3c.net - 2021-05-17 13:18 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 14:02 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 16:36 +0000
Re: Niuce C++14-feature MrSpook_rtfm7b8w@g403t8gw2b59awtit.tv - 2021-05-17 14:54 +0000
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-17 10:37 -0700
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-18 06:47 +0000
Re: Niuce C++14-feature MrSpook_w2uom3_k07@47j.ac.uk - 2021-05-18 07:30 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-18 10:31 +0000
Re: Niuce C++14-feature MrSpook_axe6hb@rq6ypc_knzvwr9.ac.uk - 2021-05-18 15:11 +0000
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-18 16:57 -0700
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-19 04:53 +0000
Re: Niuce C++14-feature Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-05-18 13:08 +0100
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-18 17:10 +0200
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-18 11:56 -0400
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-18 16:56 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-18 22:05 -0700
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-19 12:01 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-24 10:54 +0000
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-24 14:51 -0400
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-19 05:02 +0000
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-19 10:07 -0400
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-19 15:16 +0200
Re: Niuce C++14-feature Spud@nowheresville.org - 2021-05-19 07:19 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 00:53 -0700
Re: Niuce C++14-feature MrSpook_pl1c1bg7i@7sxv4z8mvmyz_.ac.uk - 2021-05-19 08:28 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:34 -0700
Re: Niuce C++14-feature MrSpook_6efnqt73nm@nyyte.com - 2021-05-19 08:44 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:50 -0700
Re: Niuce C++14-feature MrSpook_54rouunX@x37ixhgx27ymvhwc5.net - 2021-05-19 09:31 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:39 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:46 -0700
Re: Niuce C++14-feature MrSpook_nkfcgvl@7o616.biz - 2021-05-20 08:23 +0000
Re: Niuce C++14-feature Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-20 12:38 +0300
Re: Niuce C++14-feature MrSpook_5Xl@m9q7d5ux5tl8o5.co.uk - 2021-05-20 14:38 +0000
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-20 17:43 +0000
Re: Niuce C++14-feature MrSpook_dg01t9p2@m0m4iuefk1x.edu - 2021-05-21 09:16 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 13:38 +0200
Re: Niuce C++14-feature MrSpook_L1peqs_@c81ltrsr_gfoo1.co.uk - 2021-05-21 13:39 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 15:46 +0200
Re: Niuce C++14-feature MrSpook_km@gfepxabk0g_ytn7ta.net - 2021-05-21 14:48 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 17:03 +0200
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-21 14:15 +0000
Re: Niuce C++14-feature MrSpook_6f@fypmp_.biz - 2021-05-21 14:57 +0000
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-21 15:05 +0000
Re: Niuce C++14-feature "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-05-21 09:42 -0700
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-21 14:44 +0100
Re: Niuce C++14-feature MrSpook_4ptu0Yl4x9@2q77bsgmv.edu - 2021-05-21 14:47 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 05:31 +0200
Re: Niuce C++14-feature MrSpook_va6psV1d@w5lywejmkchyss0h4d.gov - 2021-05-21 09:24 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 13:33 +0200
Re: Niuce C++14-feature MrSpook_md3@zi2k.com - 2021-05-21 13:32 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 15:43 +0200
Re: Niuce C++14-feature MrSpook_zq3a8xxm@t9c1d7aq5dby4al.gov.uk - 2021-05-21 14:44 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 17:07 +0200
Re: Niuce C++14-feature MrSpook_hjgci2iT0@qtinm1mgdu.info - 2021-05-21 16:12 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 18:18 +0200
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-21 16:25 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-21 18:36 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-22 16:18 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-22 16:25 +0200
Re: Niuce C++14-feature Öö Tiib <ootiib@hot.ee> - 2021-05-22 08:44 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-22 17:49 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 05:50 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 21:32 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 06:40 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 22:07 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 22:08 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 07:46 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:12 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:19 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:20 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:22 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:27 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:30 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:32 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:35 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:38 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:41 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:44 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:49 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:50 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:52 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:54 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:56 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:59 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:03 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:04 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:09 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:11 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:34 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:36 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:38 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:39 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:43 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:46 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:55 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:00 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:02 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:05 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:07 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:08 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:10 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:32 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:33 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:34 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:37 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:40 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:53 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 08:55 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:58 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:01 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:04 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 09:07 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:10 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-25 00:01 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 23:30 -0700
Re: Niuce C++14-feature MrSpook_801o@21xmy7.gov.uk - 2021-05-24 08:31 +0000
Re: Niuce C++14-feature MrSpook_8_g@ef863gl0.eu - 2021-05-24 08:34 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 11:49 +0200
Re: Niuce C++14-feature MrSpook_9v@0v6uq5zonj66dteaq9.ac.uk - 2021-05-24 10:15 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 12:44 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-24 13:33 -0700
Re: Niuce C++14-feature MrSpook_cjz9@ngfllgqd.edu - 2021-05-25 09:02 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 12:54 +0200
Re: Niuce C++14-feature MrSpook_43zpj5@zrdy.biz - 2021-05-25 09:02 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-25 12:53 +0200
Re: Niuce C++14-feature MrSpook_m0gtwlu6_g@j_cyo9l9.edu - 2021-05-25 09:05 +0000
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-25 16:22 +0200
Re: Niuce C++14-feature MrSpook_wBhaki@w1dhf2q0pnagn57.eu - 2021-05-24 08:26 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 11:51 +0200
Re: Niuce C++14-feature MrSpook_rfg_f9lmv@xechfnrqs23y.com - 2021-05-24 10:17 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 12:45 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-24 13:42 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 13:54 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 14:19 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 15:02 +0200
Re: Niuce C++14-feature MrSpook_1shmhc5pEg@qedprf.biz - 2021-05-24 13:57 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 18:15 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-24 15:21 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 15:37 +0200
Re: Niuce C++14-feature MrSpook_61Z@avwe8ulg.co.uk - 2021-05-24 13:49 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 18:14 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-24 16:58 +0200
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-24 18:51 +0200
Re: Niuce C++14-feature MrSpook_o_4Ge4wpt@2iwg_s7sq47equu9a.edu - 2021-05-24 08:25 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-24 11:52 +0200
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-21 17:19 +0100
Re: Niuce C++14-feature MrSpook_3l@rsdtj2x7.gov - 2021-05-24 08:22 +0000
Re: Niuce C++14-feature MrSpook_f4@x4dcxggdi.eu - 2021-05-20 13:42 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 16:20 +0200
Re: Niuce C++14-feature Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-05-20 18:02 +0000
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-20 19:23 +0000
Re: Niuce C++14-feature Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-05-21 00:07 +0100
Re: Niuce C++14-feature MrSpook_db0ucj9V@o6t54wlnnja_.co.uk - 2021-05-21 09:24 +0000
Re: Niuce C++14-feature MrSpook_a102e@wnyqsthof.net - 2021-05-21 09:22 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:53 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:54 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 10:30 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:35 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:36 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 01:37 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 12:57 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:33 -0700
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-19 10:20 -0400
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 18:13 +0200
Re: Niuce C++14-feature Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-05-19 10:09 -0700
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 13:28 +0200
Re: Niuce C++14-feature MrSpook_97@bxos5xe28b1i1n7kh.ac.uk - 2021-05-17 11:34 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 13:41 +0200
Re: Niuce C++14-feature MrSpook_b89m0or3@x1_pxvs4h8sxxi.gov.uk - 2021-05-17 13:29 +0000
Re: Niuce C++14-feature MrSpook_imhoou@kq9.ac.uk - 2021-05-17 15:53 +0000
Re: Niuce C++14-feature MrSpook_qg11H@ihwz2zmflqtcalb.gov.uk - 2021-05-17 16:06 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 18:21 +0200
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 16:38 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 17:58 +0200
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 14:03 +0000
Re: Niuce C++14-feature Juha Nieminen <nospam@thanks.invalid> - 2021-05-17 16:37 +0000
Re: Niuce C++14-feature MrSpook_7kof@5x9.edu - 2021-05-18 07:27 +0000
Re: Niuce C++14-feature MrSpook_cOJ9@yr_8g_4nz.com - 2021-05-17 14:55 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 16:06 +0200
Re: Niuce C++14-feature MrSpook_tt7xetn_st@d3zd4ilmme.gov - 2021-05-17 14:56 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-17 17:20 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-18 17:20 +0200
Re: Niuce C++14-feature MrSpook_h2j5v@jq7cn18h8lm.com - 2021-05-18 15:35 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-18 17:57 +0200
Re: Niuce C++14-feature MrSpook_0by_disXi@2hd58e950gxh.eu - 2021-05-19 07:22 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 09:41 +0200
Re: Niuce C++14-feature MrSpook_ox7@4ieqo8ddusd3k1c8k.com - 2021-05-19 08:22 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 10:28 +0200
Re: Niuce C++14-feature MrSpook_4t1542s@nz48t.gov - 2021-05-19 08:40 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 12:54 +0200
Re: Niuce C++14-feature MrSpook_2ur@t65zb.com - 2021-05-19 11:08 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 13:11 +0200
Re: Niuce C++14-feature MrSpook_a9r7@vdgtzl3x.gov.uk - 2021-05-19 11:19 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 13:33 +0200
Re: Niuce C++14-feature MrSpook_of0j0vqHff@bap.com - 2021-05-19 13:29 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 16:17 +0200
Re: Niuce C++14-feature MrSpook_83b6en@o2cr9.ac.uk - 2021-05-19 14:57 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 17:49 +0200
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-19 17:41 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 19:55 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 14:02 -0700
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-19 21:06 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 14:12 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 14:13 -0700
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-20 12:16 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 12:31 +0200
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 12:33 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-20 18:37 +0200
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-20 13:10 -0400
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-20 17:56 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-20 20:26 +0200
Re: Niuce C++14-feature "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-05-20 19:50 -0700
Re: Niuce C++14-feature scott@slp53.sl.home (Scott Lurndal) - 2021-05-20 14:35 +0000
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:54 -0700
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-19 13:58 -0700
Re: Niuce C++14-feature David Brown <david.brown@hesbynett.no> - 2021-05-19 11:16 +0200
Re: Niuce C++14-feature MrSpook_V1@aikd06tg1ez2i6hqi9.com - 2021-05-19 09:29 +0000
Re: Niuce C++14-feature Paavo Helde <myfirstname@osa.pri.ee> - 2021-05-19 13:36 +0300
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 12:56 +0200
Re: Niuce C++14-feature MrSpook_w5c@g2nz1m_2f4r2g8wqvgfd.co.uk - 2021-05-19 11:07 +0000
Re: Niuce C++14-feature James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-05-19 10:34 -0400
Re: Niuce C++14-feature MrSpook_g1@mpi.com - 2021-05-19 14:55 +0000
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-19 16:15 +0000
Re: Niuce C++14-feature MrSpook_uc82glu@4o0o4n889yatl8.ac.uk - 2021-05-20 08:19 +0000
Re: Niuce C++14-feature Mr Flibble <flibble@reddwarf.jmc> - 2021-05-20 17:46 +0000
Re: Niuce C++14-feature MrSpook_mm9v3kgmmm@7_o9.co.uk - 2021-05-21 09:19 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-18 17:56 +0200
Re: Niuce C++14-feature Manfred <noname@add.invalid> - 2021-05-18 20:03 +0200
Re: Niuce C++14-feature MrSpook_fDx9@a3i3cdf7_.info - 2021-05-19 07:27 +0000
Re: Niuce C++14-feature Bonita Montero <Bonita.Montero@gmail.com> - 2021-05-19 09:41 +0200
Re: Niuce C++14-feature "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-05-18 15:14 -0700
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-05-21 15:05 +0000 |
| Message-ID | <4%PpI.243822$N_4.83360@fx36.iad> |
| In reply to | #79691 |
MrSpook_6f@fypmp_.biz writes: >On Fri, 21 May 2021 14:15:29 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: >>MrSpook_L1peqs_@c81ltrsr_gfoo1.co.uk writes: >>>On Fri, 21 May 2021 13:38:03 +0200 >>>Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>> Oracle uses this method for good reason. ... >>>>Look at MS SQL Server - a DB-Server with a much modern architecture >>>>- it runs solid with MT since the first version in the 90s. >>> >>>Clearly you never used the early versions. No one would bet their company >>>on SQL Server back then, it was an unreliable toy compared to Oracle. >> >>Sybase (the code base that SQL Server was based on) was a fairly >>robust and popular RDBMS in the day. Of course, SQL server ran on unix > >Sybase was ok, I used it for quite a long time in finance as it was popular >there due to a much lower install cost than Oracle. To give it credit T/SQL is >a much nicer language than Oracles PL/SQL, but its dirty read transaction >system was hopeless and it had no deadlock handling mechanism other than the >kill one of the deadlocked processes which is frankly fucking useless and a >PITA when it happens in the middle of the night - which it did, often. Oracle >when presented with a deadlock does a silent rollback on one of the >transactions and suspends it until it can proceed. > >> 1993: Sybase and Microsoft dissolve their partnership. Microsoft >> receives a copy of the SQL Server code base. In exchange Sybase >> is free to deploy on the x86 platform which has now become the >> chip of choice for Unix. Sybase SQL Server version 4.2 and Microsoft > >x86 chip of choice for Unix in 93? Who wrote that, Darl McBride? PA-RISC and >Sparc had the unix space carved up between them back then with RS/6000 bringing >up the rear. x86 was SCO which was a bit part player in the unix arena. By 1993, USL had given up on 3B2 and was focused on x86 for SVR4 (and successors) and Sequent owned the larger database unix systems.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2021-05-21 09:42 -0700 |
| Message-ID | <51d19e46-7463-4ca0-8436-e7343421735an@googlegroups.com> |
| In reply to | #79687 |
On Friday, May 21, 2021 at 10:15:45 AM UTC-4, Scott Lurndal wrote: > MrSpook_L1peqs_@c81ltrsr_gfoo1.co.uk writes: > >On Fri, 21 May 2021 13:38:03 +0200 > >Bonita Montero <Bonita....@gmail.com> wrote: > >>> Oracle uses this method for good reason. ... > >>Look at MS SQL Server - a DB-Server with a much modern architecture > >>- it runs solid with MT since the first version in the 90s. > > > >Clearly you never used the early versions. No one would bet their company > >on SQL Server back then, it was an unreliable toy compared to Oracle. > Sybase (the code base that SQL Server was based on) was a fairly > robust and popular RDBMS in the day. Of course, SQL server ran on unix > at that time (Ashton-Tate/Microsoft SQL Server 1.0). Microsoft received > sole license to x86 in 1988. > > August 1991: Sybase goes public at a split adjusted price of $4.40. Indeed. Before the IPO, employees held options on x number of shares at $2.20. Just before the IPO, Sybase did a reverse split, and suddenly the employees had options on x/2 shares at $4.40. In any case, the employees did well, I think I sold mine about a year later for $50. > Sybase SQL server 4.0, and later 4.8 (the first smp server) > and 4.9.1, all outperformed competitors by significant margins > in standard benchmarks. In the mid to late 80's, Sybase used their own implementation of "cooperative threads" on a number of UNIX RISC boxes and VAX VMS. Consequently Sybase SQL Server could handle multiple connection requests with a single process, whereas Oracle required one process per connection, and required about half a megabyte of memory per connection. Sybase also used a simpler locking mechanism than Oracle, using page locking rather than row locking. Oracle's row locking was in principle better, but it could only keep track of a limited number of rows, and often escalated to table locks. These factors gave Sybase a big advantage for on-line applications, and it quickly established itself in that space, especially with brokerage companies and wholesale banks that needed to develop on-line trading systems for derivative products. In the late 1980's, Sybase did outperform Oracle on benchmarks by some margin. However, when multiprocessing hardware became widely available by the early to mid 1990's, the situation was reversed. Oracle's dumb one connection per process could scale easily on these machines, but not Sybase's cooperative threading. > 1993: Sybase and Microsoft dissolve their partnership. Microsoft > receives a copy of the SQL Server code base. In exchange Sybase > is free to deploy on the x86 platform which has now become the > chip of choice for Unix. My understanding at the time was that the agreement was that Microsoft had the sole right for Windows and OS/2 systems, and Sybase for UNIX and VAX. Sybase originally thought Windows was unimportant, but panicked when NT came out. Sybase became desperate to get out of the agreement, while Microsoft thought it was fine the way it was. The only way Sybase could get out of it was basically by giving away the rights to SQL Server. Sybase then did make a version of SQL Server for Windows NT, but it was unsuccessful, Microsoft owned that space. > Sybase SQL Server version 4.2 and Microsoft > SQL Server are identical. I don't believe that's true. Microsoft claimed to have rewritten the internals. Their initial version on OS/2 certainly supported native OS/2 threads. > Their Transact-SQL (T-SQL) procedural > language is the same, as is the basic process architecture. From this > point the products diverge as Microsoft includes more Windows features > whilst Sybase adds Enterprise features (performance and scaling). > > > Sybase was noted for storing data in columns rather than rows. > Not SQL Server, SQL Server was implemented as a B-Tree with rows in pages, the same as Oracle. You're thinking about Sybase IQ, which was a business analytics tool, introduced around 1996. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2021-05-21 14:44 +0100 |
| Message-ID | <20210521144403.00000c65@reddwarf.jmc> |
| In reply to | #79674 |
On Fri, 21 May 2021 09:16:55 +0000 (UTC) MrSpook_dg01t9p2@m0m4iuefk1x.edu wrote: > On Thu, 20 May 2021 17:43:40 GMT > Mr Flibble <flibble@reddwarf.jmc> wrote: > >On Thu, 20 May 2021 14:38:16 +0000, MrSpook_5Xl wrote: > > > >> On Thu, 20 May 2021 16:20:24 +0200 Bonita Montero > >> <Bonita.Montero@gmail.com> wrote: > >>>> I disagree. The windows process model which starts a new process > >>>> from the beginning each time with no state carried over (except > >>>> for command line args) > >>> > >>>> is extremely limited in its usefulness. Posix can do that plus > >>>> fork at a > >>>given > >>>> point with the new process being a carbon copy of the old one ... > >>> > >>>This is good for nothing. > >> > >> Keep demonstrating your ignorance, its very amusing :) > > > >Do you even know why fork() actually exists? Because back in the day > >THREADS weren't a thing. If you want to COPY lots of program state > >using > > Threads were a thing back in mainframe days you dick, along with VMs > too. > > >fork() then why the fuck aren't you using threads? Processes are > > Because in serious applications - ie nothing you write I was part of the team that invented the smartphone, dear, quite serious I think considering billions of people now have a smartphone in their pocket. > - robustness > trumps speed of creation. A single process starts, loads up init then > when a user or some other event needs servicing you fire off a > seperate process so if that process dies it doesn't take town the > whole fucking application. Oracle uses this method for good reason. > Some browsers recently switched to a process-per-tab model too. The argument isn't about spawning separate processes, dear, the argument is threads vs fork(). > > It always amuses me when people who've only ever coded on windows > spout a load of crap about things they know nothing about. I've written code for various platforms including: * Sinclair BASIC * MS-DOS * Windows * HP-UX * QNX * Linux > > >heavyweight OS primitives compared to threads. These days fork() and > >associated horribleness like Linux's overcommit are an anachronism. > > Whatever you say Dilbert. Ah, the ad hominem, the last resort of the fractally wrong. > > https://dilbert.com/strip/1995-06-24 Dilbert is a good comic strip, possibly the only thing we can agree on given you appear to be a fucktarded cockwomble. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_4ptu0Yl4x9@2q77bsgmv.edu |
|---|---|
| Date | 2021-05-21 14:47 +0000 |
| Message-ID | <s88h6s$11j5$1@gioia.aioe.org> |
| In reply to | #79684 |
On Fri, 21 May 2021 14:44:03 +0100 Mr Flibble <flibble@reddwarf.jmc> wrote: >On Fri, 21 May 2021 09:16:55 +0000 (UTC) >MrSpook_dg01t9p2@m0m4iuefk1x.edu wrote: >> >fork() then why the fuck aren't you using threads? Processes are >> >> Because in serious applications - ie nothing you write > >I was part of the team that invented the smartphone, dear, quite ROTFL!!!! Of course you were Walter, of course! :) Do tell us more... were you the tea boy? >> trumps speed of creation. A single process starts, loads up init then >> when a user or some other event needs servicing you fire off a >> seperate process so if that process dies it doesn't take town the >> whole fucking application. Oracle uses this method for good reason. >> Some browsers recently switched to a process-per-tab model too. > >The argument isn't about spawning separate processes, dear, the >argument is threads vs fork(). For the purpose of this argument its the same thing. >> It always amuses me when people who've only ever coded on windows >> spout a load of crap about things they know nothing about. > >I've written code for various platforms including: >* Sinclair BASIC Wow, look at you! >* MS-DOS >* Windows >* HP-UX >* QNX >* Linux You mean you wrote some code that happened to compile on the last 3. >> >heavyweight OS primitives compared to threads. These days fork() and >> >associated horribleness like Linux's overcommit are an anachronism. >> >> Whatever you say Dilbert. > >Ah, the ad hominem, the last resort of the fractally wrong. You dish it out, so take it like a man.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-21 05:31 +0200 |
| Message-ID | <s879hp$p31$1@dont-email.me> |
| In reply to | #79659 |
>> This is good for nothing. > Keep demonstrating your ignorance, its very amusing :) Parallelism is today done with threads. No one uses fork()ing anymore.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_va6psV1d@w5lywejmkchyss0h4d.gov |
|---|---|
| Date | 2021-05-21 09:24 +0000 |
| Message-ID | <s87u8r$1n5a$1@gioia.aioe.org> |
| In reply to | #79673 |
On Fri, 21 May 2021 05:31:05 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> This is good for nothing. > >> Keep demonstrating your ignorance, its very amusing :) > >Parallelism is today done with threads. >No one uses fork()ing anymore. They do. Go program in unix for a few years then get back to me.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-21 13:33 +0200 |
| Message-ID | <s885qo$76p$1@dont-email.me> |
| In reply to | #79678 |
>> Parallelism is today done with threads. >> No one uses fork()ing anymore. > They do. Go program in unix for a few years then get back to me. That's long ago. Today everything written new is threaded and by far most of the old fork()ed applications are migrated to multi-threading. That's because MT-code is easier to write and much more performant when synchronizing.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_md3@zi2k.com |
|---|---|
| Date | 2021-05-21 13:32 +0000 |
| Message-ID | <s88coh$q7l$1@gioia.aioe.org> |
| In reply to | #79679 |
On Fri, 21 May 2021 13:33:43 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Parallelism is today done with threads. >>> No one uses fork()ing anymore. > >> They do. Go program in unix for a few years then get back to me. > >That's long ago. Today everything written new is threaded and by far >most of the old fork()ed applications are migrated to multi-threading. Oh right. When did you last work on a large unix application codebase? >That's because MT-code is easier to write and much more performant when >synchronizing. You don't seem to understand that not all applications require tightly coupled flows of control. Threading has specific use cases, multi process has others. You're young and clearly have only ever used Windows probably on single CPU machines so you only see the world from a Windows POV with its crippled process model and reliance on threading because of this. When you've worked on a unix (or even VMS) with multiple CPUs (not just cores) which the application needs to use you'll have different persective then maybe you can discuss this topic. Until then you're just making yourself look stupid.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-21 15:43 +0200 |
| Message-ID | <s88de5$mrm$1@dont-email.me> |
| In reply to | #79681 |
> You don't seem to understand that not all applications require tightly coupled > flows of control. ... Almost any application wich is parallel needs this. Because of that there are no new applications that use fork()ing. > Threading has specific use cases, multi process has others. No, threading replaces fork()ing. > You're young and clearly have only ever used Windows probably on single CPU > machines ... Whether you need on or the other kind of parallelism has nothing to do if you have true multiprocessing or a single CPU. > When you've worked on a unix (or even VMS) with multiple CPUs (not just cores) > which the application needs to use you'll have different persective then maybe > you can discuss this topic. Until then you're just making yourself look stupid. You're naive.
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_zq3a8xxm@t9c1d7aq5dby4al.gov.uk |
|---|---|
| Date | 2021-05-21 14:44 +0000 |
| Message-ID | <s88h0q$ulr$1@gioia.aioe.org> |
| In reply to | #79683 |
On Fri, 21 May 2021 15:43:30 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >> You don't seem to understand that not all applications require tightly >coupled >> flows of control. ... > >Almost any application wich is parallel needs this. Because No applications need multiple CPUs? Sure about that? >of that there are no new applications that use fork()ing. Presumably have proof of this so please give a URL. >> Threading has specific use cases, multi process has others. > >No, threading replaces fork()ing. > >> You're young and clearly have only ever used Windows probably on single CPU >> machines ... > >Whether you need on or the other kind of parallelism has nothing >to do if you have true multiprocessing or a single CPU. Thank you for proving my point. >> When you've worked on a unix (or even VMS) with multiple CPUs (not just >cores) >> which the application needs to use you'll have different persective then >maybe >> you can discuss this topic. Until then you're just making yourself look >stupid. > >You're naive. Thats a nice hole you're digging for youself.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-21 17:07 +0200 |
| Message-ID | <s88ic2$uh1$1@dont-email.me> |
| In reply to | #79688 |
>> Almost any application wich is parallel needs this. Because > No applications need multiple CPUs? Sure about that? Wer're talking about MT vs. fork()ing, dude. > Presumably have proof of this so please give a URL. I don't have to prove this. Having foked() app with the least coupling of the parallel processsing is much harder to write with fork()ing than with MT. Shared-memory, named pipes and semaphores are much more compli- cated to handle than a single shared address-space with simple mutexes and condition-variables. And even more: this kind of parallelism is usually more performant than forked() synchronization (f.e. consider that a uncontended mutex-lock is only about a few dozen cycles in a MT-environment).
[toc] | [prev] | [next] | [standalone]
| From | MrSpook_hjgci2iT0@qtinm1mgdu.info |
|---|---|
| Date | 2021-05-21 16:12 +0000 |
| Message-ID | <s88m5r$1jd1$1@gioia.aioe.org> |
| In reply to | #79694 |
On Fri, 21 May 2021 17:07:44 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Almost any application wich is parallel needs this. Because > >> No applications need multiple CPUs? Sure about that? > >Wer're talking about MT vs. fork()ing, dude. You don't even know what I'm talking refering to do you? Having threads of a single application spread over multiple CPUs requires specialist hardware and can cause serious performance bottlenecks. The same restriction does not apply to multiprocess. >> Presumably have proof of this so please give a URL. > >I don't have to prove this. Having foked() app with the least coupling Yes you do. Now provide some proof or STFU. >of the parallel processsing is much harder to write with fork()ing than >with MT. Shared-memory, named pipes and semaphores are much more compli- >cated to handle than a single shared address-space with simple mutexes >and condition-variables. And even more: this kind of parallelism is >usually more performant than forked() synchronization (f.e. consider >that a uncontended mutex-lock is only about a few dozen cycles in a >MT-environment). Nice cut and paste. A) Stop using that idiotic made up word "performant". It doesn't make you sound clever, more like a dumb sheep following the herd. B) As I already said if you could bloody read, not all execution paths require close synchronisation but some DO require seperation of memory and isolation from errors - eg ssh connections. You don't want all user connections sharing the same memory in an application that involves encrypted data or every user being kicked off if 1 thread crashes you fucking mouth breathing moron! So guess what, sshd forks a new process per connection! Now spend the weekend getting a clue and dont bother replying until you have one.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-21 18:18 +0200 |
| Message-ID | <s88mfs$pm$1@dont-email.me> |
| In reply to | #79695 |
> You don't even know what I'm talking refering to do you? Having threads of > a single application spread over multiple CPUs requires specialist hardware > and can cause serious performance bottlenecks. ... The necessities of synchronization are the _same_ for fork()ing and MT, i.e. you need to share memory at the same places in the code and you need to synchronize also at the same places. But MT is more effi- cient because of the shared address-space - a lot of synchronization then doesn't need any kernel-aid - and easier to write. Your knowledge is very superficial when it comes to parallelization !
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-05-21 16:25 +0000 |
| Message-ID | <2aRpI.173185$wd1.36700@fx41.iad> |
| In reply to | #79696 |
Bonita Montero <Bonita.Montero@gmail.com> writes: <ATTRIBUTION DELETED INTENTIONALLY BY BM> >> You don't even know what I'm talking refering to do you? Having threads of >> a single application spread over multiple CPUs requires specialist hardware >> and can cause serious performance bottlenecks. ... > >The necessities of synchronization are the _same_ for fork()ing and >MT, i.e. you need to share memory at the same places in the code and >you need to synchronize also at the same places. But MT is more effi- >cient because of the shared address-space - a lot of synchronization >then doesn't need any kernel-aid - and easier to write. >Your knowledge is very superficial when it comes to parallelization ! You are both arguing past each other. Both forking and multithreading are useful in the right situation.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-21 18:36 +0200 |
| Message-ID | <s88nj3$902$1@dont-email.me> |
| In reply to | #79698 |
> Both forking and multithreading are useful in the right situation. fork()ing is almost never used today for parallelism.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-05-22 16:18 +0200 |
| Message-ID | <s8b3s2$vc5$1@dont-email.me> |
| In reply to | #79698 |
On 21/05/2021 18:25, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: > <ATTRIBUTION DELETED INTENTIONALLY BY BM> >>> You don't even know what I'm talking refering to do you? Having threads of >>> a single application spread over multiple CPUs requires specialist hardware >>> and can cause serious performance bottlenecks. ... >> >> The necessities of synchronization are the _same_ for fork()ing and >> MT, i.e. you need to share memory at the same places in the code and >> you need to synchronize also at the same places. But MT is more effi- >> cient because of the shared address-space - a lot of synchronization >> then doesn't need any kernel-aid - and easier to write. >> Your knowledge is very superficial when it comes to parallelization ! > > You are both arguing past each other. > > Both forking and multithreading are useful in the right situation. > Yes - that is so obvious that it is hard to understand how these two can be having an argument. Forking is best when you need separation between the parts and they should have little connection - sshd was given as an example. It is also good if there is a risk of crashing or security breaches, as failures will not be as catastrophic. Threading is best when you have threads working together to improve the throughput of a single task or need lots of communication and shared data. So for some tasks, one choice is obviously much better than the other, for other tasks either will work, or a combination, or other factors dominate. But arguing whether multithreading or forking is best is like arguing whether trains or planes are best.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-22 16:25 +0200 |
| Message-ID | <s8b48n$653$1@dont-email.me> |
| In reply to | #79717 |
> But arguing whether multithreading or forking is best is like arguing > whether trains or planes are best. Mostly you have a lot of coupling when you have parallel code. Then fork()ing is a lot of work and less efficient.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-05-22 08:44 -0700 |
| Message-ID | <5c19f7c2-0eba-41a6-ae47-f663a3bacdfdn@googlegroups.com> |
| In reply to | #79718 |
On Saturday, 22 May 2021 at 17:25:43 UTC+3, Bonita Montero wrote: restoring attribution > On Saturday, 22 May 2021 at 17:18:58 UTC+3, David Brown wrote: > > But arguing whether multithreading or forking is best is like arguing > > whether trains or planes are best. > > Mostly you have a lot of coupling when you have parallel code. > Then fork()ing is a lot of work and less efficient. The goal of reducing coupling to as close as it is possible to embarrassingly parallel is same to both. Otherwise the threads will just hang behind semaphores most of the time and the whole concurrency was futile waste of development time into producing pointlessly complicated code and to achieve drop in efficiency.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-22 17:49 +0200 |
| Message-ID | <s8b973$5jh$1@dont-email.me> |
| In reply to | #79720 |
> The goal of reducing coupling to as close as it is possible to > embarrassingly parallel is same to both. embarrassingly parallel doesn't automatically mean there's not much coupling. There could be a lot of shared data f.e..
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-05-25 05:50 +0200 |
| Message-ID | <s8hs5p$pdl$1@dont-email.me> |
| In reply to | #79718 |
>> Mutexes alone aren't there for procuder-consumer-relationships. >> But usually they're used alone when there's no contention when >> also employing a CV. A mutex plus a CV is almost the fastest >> producer-consumer-mechanism (monitor-objects are the fastest). > Is that a troll? Why ?
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web