Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #118907 > unrolled thread
| Started by | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| First post | 2024-04-29 19:13 +0300 |
| Last post | 2024-04-30 16:48 +0000 |
| Articles | 20 on this page of 138 — 13 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-29 19:13 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 20:29 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 13:33 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-29 22:41 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-29 16:46 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-04-30 00:11 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 06:54 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 07:10 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:13 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 08:53 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:59 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 20:34 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 05:45 +0200
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-02 15:53 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 17:10 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:24 +0000
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 09:38 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:58 +0200
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 11:18 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 13:23 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:01 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 17:18 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:20 +0000
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-04 20:41 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-05 01:41 +0000
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-05 10:38 +0300
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-05 12:37 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-05 13:00 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-13 00:43 +0000
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-13 15:04 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-13 16:52 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-17 22:18 +0000
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-17 22:17 +0000
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-06 15:13 -0700
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-07 08:41 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-07 11:00 +0200
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-13 19:43 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 04:59 +0200
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 16:39 -0700
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-14 13:53 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 13:42 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 19:55 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 14:11 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 20:16 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 16:02 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-14 13:34 -0700
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 19:46 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-14 14:13 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-14 20:28 +0800
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-14 16:24 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 03:29 +0800
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-14 23:34 +0300
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 08:31 +0800
Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-14 18:16 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:26 +0200
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 11:06 +0300
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 16:34 -0700
Re: Threads across programming languages olcott <polcott333@gmail.com> - 2024-05-21 18:43 -0500
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:25 +0200
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 20:48 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 06:23 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-14 21:37 -0700
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 19:57 +0800
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 20:07 +0800
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 17:33 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-15 08:43 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 17:55 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-15 10:31 -0700
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-15 11:20 +0200
Re: Threads across programming languages wij <wyniijj5@gmail.com> - 2024-05-15 22:38 +0800
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-15 20:46 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-15 21:51 +0200
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 19:30 -0700
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-06-04 09:03 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-15 14:24 +0300
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 19:26 -0700
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 20:27 -0700
Re: Threads across programming languages Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-22 11:43 +0300
Re: Threads across programming languages Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-01 21:03 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:21 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 08:45 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:05 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:09 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 02:33 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:05 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:07 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:09 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 06:00 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:19 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-05 01:40 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-04 22:23 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 05:39 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 07:53 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:16 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 09:00 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 02:30 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 20:36 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-04 04:46 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:50 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 06:00 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 21:27 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 13:28 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-02 23:15 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 16:58 -0700
Re: Threads across programming languages Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-03 00:15 +0000
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 17:22 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-03 00:07 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 02:25 +0000
Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-03 12:33 -0700
Re: Threads across programming languages Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-05-07 20:48 -0700
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-03 10:34 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:05 +0300
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-03 17:20 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-03 18:47 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:19 +0000
Re: Threads across programming languages bart <bc@freeuk.com> - 2024-05-04 00:27 +0100
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-04 22:04 +0300
Re: Threads across programming languages David Brown <david.brown@hesbynett.no> - 2024-05-05 14:56 +0200
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-04 17:36 +0200
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-04 22:11 +0300
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-04 12:59 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 22:20 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 22:22 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 11:55 -0700
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-01 11:55 -0700
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 06:53 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 07:09 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 10:11 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 08:53 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-01 11:00 +0200
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 20:31 +0000
Re: Threads across programming languages scott@slp53.sl.home (Scott Lurndal) - 2024-05-01 21:00 +0000
Re: Threads across programming languages Michael S <already5chosen@yahoo.com> - 2024-05-02 00:05 +0300
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-01 23:05 +0000
Re: Threads across programming languages Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-02 05:46 +0200
Re: Threads across programming languages "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-05-02 13:33 -0700
Re: Threads across programming languages Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-03 22:22 +0000
Re: Threads across programming languages scott@slp53.sl.home (Scott Lurndal) - 2024-04-30 16:48 +0000
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-05-03 21:27 -0700 |
| Message-ID | <v14dff$1196p$2@dont-email.me> |
| In reply to | #119039 |
On 5/3/2024 9:00 PM, Bonita Montero wrote: > Am 04.05.2024 um 04:30 schrieb Lawrence D'Oliveiro: >> On Fri, 3 May 2024 09:00:30 +0200, Bonita Montero wrote: >> >>> Am 03.05.2024 um 01:16 schrieb Lawrence D'Oliveiro: >>> >>>> On Thu, 2 May 2024 07:53:21 +0200, Bonita Montero wrote: >>>> >>>>> If you have a stream of individual I/Os and the processing of the I/Os >>>>> takes more time than the time between the I/Os you need threads. >>>> >>>> That makes the CPU the bottleneck. Which is not the case we’re >>>> discussing here. >>> >>> No, the processing beetween the I/O can mostly depend on other I/Os, >>> which is the standard case for server applications. >> >> In that situation, multithreading isn’t going to speed things up. > > Of course if the intervals between the individual I/Os are shorter > than the processing. > Think of some io completion threads going full speed. They do not actually block for hours during a period of heavy load. GQCSEX is returning shit loads of OVERLAPPED io completions and it never blocks for this heavy period in load... Then, thread sync can become a major factor... Ahhh... RCU with database lookups is able to handle HYPER read mostly loads...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-05-02 13:28 -0700 |
| Message-ID | <v10t0v$20cs$1@dont-email.me> |
| In reply to | #118974 |
On 5/1/2024 10:39 PM, Lawrence D'Oliveiro wrote: > On Wed, 1 May 2024 22:20:47 -0700, Chris M. Thomasson wrote: > >> On 5/1/2024 1:34 PM, Lawrence D'Oliveiro wrote: >> >>> Remember, we’re talking about maximizing I/O throughput here, so CPU is >>> not the bottleneck. >> >> It can be if your thread synchronization scheme is sub par. > > Another reason to avoid threads. Why? Believe it or not, there are ways to create _highly_ scalable thread synchronization schemes. Using a global lock is not one of them... :^) For database servers, RCU is probably the best you can get. It simply shines for read mostly workloads. > So long as your async tasks have an await > call somewhere in their main loops, that should be sufficient to avoid > most bottlenecks. async tasks are using threads... No? Also, what type of synchronization schemes are they using under the covers? I would hope they are using some efficient lock and/or wait free algorithms. I have a lot of experience in this area.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-02 23:15 +0000 |
| Message-ID | <v116q4$4at1$1@dont-email.me> |
| In reply to | #118987 |
On Thu, 2 May 2024 13:28:15 -0700, Chris M. Thomasson wrote: > On 5/1/2024 10:39 PM, Lawrence D'Oliveiro wrote: >> >> On Wed, 1 May 2024 22:20:47 -0700, Chris M. Thomasson wrote: >> >>> On 5/1/2024 1:34 PM, Lawrence D'Oliveiro wrote: >>> >>>> Remember, we’re talking about maximizing I/O throughput here, so CPU >>>> is not the bottleneck. >>> >>> It can be if your thread synchronization scheme is sub par. >> >> Another reason to avoid threads. > > Why? Believe it or not, there are ways to create _highly_ scalable > thread synchronization schemes. I’m sure there are. But none of that is relevant when the CPU isn’t the bottleneck anyway. >> So long as your async tasks have an await call somewhere in their main >> loops, that should be sufficient to avoid most bottlenecks. > > async tasks are using threads... No? No. They are built on coroutines. Specifically, the “stackless” variety. <https://gitlab.com/ldo/python_topics_notebooks/-/blob/master/Generators%20&%20Coroutines.ipynb?ref_type=heads>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-05-02 16:58 -0700 |
| Message-ID | <v119bu$4pfa$1@dont-email.me> |
| In reply to | #118990 |
On 5/2/2024 4:15 PM, Lawrence D'Oliveiro wrote: > On Thu, 2 May 2024 13:28:15 -0700, Chris M. Thomasson wrote: > >> On 5/1/2024 10:39 PM, Lawrence D'Oliveiro wrote: >>> >>> On Wed, 1 May 2024 22:20:47 -0700, Chris M. Thomasson wrote: >>> >>>> On 5/1/2024 1:34 PM, Lawrence D'Oliveiro wrote: >>>> >>>>> Remember, we’re talking about maximizing I/O throughput here, so CPU >>>>> is not the bottleneck. >>>> >>>> It can be if your thread synchronization scheme is sub par. >>> >>> Another reason to avoid threads. >> >> Why? Believe it or not, there are ways to create _highly_ scalable >> thread synchronization schemes. > > I’m sure there are. But none of that is relevant when the CPU isn’t the > bottleneck anyway. The CPU can become a bottleneck. Depends on how the programmer implements things. >>> So long as your async tasks have an await call somewhere in their main >>> loops, that should be sufficient to avoid most bottlenecks. >> >> async tasks are using threads... No? > > No. They are built on coroutines. Specifically, the “stackless” variety. > > <https://gitlab.com/ldo/python_topics_notebooks/-/blob/master/Generators%20&%20Coroutines.ipynb?ref_type=heads> So, there is no way to take advantage of multiple threads on Python? Heck, even JavaScript has WebWorkers... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-05-03 00:15 +0000 |
| Message-ID | <20240502171354.89@kylheku.com> |
| In reply to | #118994 |
On 2024-05-02, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > The CPU can become a bottleneck. Unfortunately, not in a way that you could use for playing slide guitar, let alone actually drinking beer through it. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-05-02 17:22 -0700 |
| Message-ID | <v11ann$52ol$1@dont-email.me> |
| In reply to | #118995 |
On 5/2/2024 5:15 PM, Kaz Kylheku wrote:
> On 2024-05-02, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> The CPU can become a bottleneck.
>
> Unfortunately, not in a way that you could use for playing slide
> guitar, let alone actually drinking beer through it.
>
:^D The problem is that I have had to debug server code that actually
locked a global mutex ala:
for (;;)
{
io_complete& io = wait_for_io(INFINITE);
lock();
io.foobar();
unlock();
}
Oh shit.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-05-03 00:07 -0700 |
| Message-ID | <v122gd$ddcf$1@dont-email.me> |
| In reply to | #118996 |
On 5/2/2024 5:22 PM, Chris M. Thomasson wrote:
> On 5/2/2024 5:15 PM, Kaz Kylheku wrote:
>> On 2024-05-02, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> The CPU can become a bottleneck.
>>
>> Unfortunately, not in a way that you could use for playing slide
>> guitar, let alone actually drinking beer through it.
>>
>
> :^D The problem is that I have had to debug server code that actually
> locked a global mutex ala:
>
> for (;;)
> {
> io_complete& io = wait_for_io(INFINITE);
>
> lock();
> io.foobar();
A fun part...
io.foobar() does some things that might call lock() again, during
certain scenarios. Oh, so the programmers says, well, lock() needs to be
recursive... Oh, well, it seems to work. Deadlock! Shit!
> unlock();
> }
>
> Oh shit.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-03 02:25 +0000 |
| Message-ID | <v11hvg$aajl$1@dont-email.me> |
| In reply to | #118994 |
On Thu, 2 May 2024 16:58:54 -0700, Chris M. Thomasson wrote: > The CPU can become a bottleneck. Then that becomes an entirely different situation from what we’re discussing. > So, there is no way to take advantage of multiple threads on Python? There is, but the current scheme has limitations in CPU-intensive situations. They’re working on a fix, without turning it into a memory hog like Java.
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-05-03 12:33 -0700 |
| Message-ID | <CuWdneEdN-eZoaj7nZ2dnZfqnPWdnZ2d@giganews.com> |
| In reply to | #118998 |
On 05/02/2024 07:25 PM, Lawrence D'Oliveiro wrote: > On Thu, 2 May 2024 16:58:54 -0700, Chris M. Thomasson wrote: > >> The CPU can become a bottleneck. > > Then that becomes an entirely different situation from what we’re > discussing. > >> So, there is no way to take advantage of multiple threads on Python? > > There is, but the current scheme has limitations in CPU-intensive > situations. They’re working on a fix, without turning it into a memory hog > like Java. > Yeah, it can be that way. "How are things?" "Yesterday I implemented an entire web service on the cloud." "Oh, really, how'd that go?" "I opened Initializer and added a starter and copied how to pop the queue and put the queue name in a file, then I added it to git and it went into the CICD pipeline and now it's in Prod." "Great." "It only even needs 1 gigabyte of RAM." Surely when it's like, "the only time this framework app uses 1 gigabyte of RAM is at boot time it totally templates itself into a gigabyte of RAM", then the guy's like "see, I'm totally not using RAM." Yet it's like, "well, yeah, but the meter for the RAM you're not using is on". At least then for re-routines, and if it helps it's quite an idee fixe at this point, it's clear as described they can be implemented in most languages with or without threads as with just a minimum of threads and thread locals and exception handling being well-defined and the most usual sort of procedural call stack, then, get this: taking plain usual code, giving it a ton of threads, making every invocation one of these things, and automatically parallelizing the code automatically according to the flow-graph dependencies declared in the synchronous, blocking, routine. Now _that's_ ridiculous. Though, in C++ with this sort of approach, the only sort of "unusable" object is a future<result<T, E>> as it were, or "the ubiquitous type" sort of thing then as to overload its access as to invoke "get()", if there was a sort of way to overload the "." and "->" operators, and have them most simply be compiled as invoke "." and "->". Does std::identity work this way?
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2024-05-07 20:48 -0700 |
| Message-ID | <haqdneZd5-puaKf7nZ2dnZfqnPudnZ2d@giganews.com> |
| In reply to | #119024 |
On 05/03/2024 12:33 PM, Ross Finlayson wrote: > On 05/02/2024 07:25 PM, Lawrence D'Oliveiro wrote: >> On Thu, 2 May 2024 16:58:54 -0700, Chris M. Thomasson wrote: >> >>> The CPU can become a bottleneck. >> >> Then that becomes an entirely different situation from what we’re >> discussing. >> >>> So, there is no way to take advantage of multiple threads on Python? >> >> There is, but the current scheme has limitations in CPU-intensive >> situations. They’re working on a fix, without turning it into a memory >> hog >> like Java. >> > > > Yeah, it can be that way. "How are things?" "Yesterday > I implemented an entire web service on the cloud." > "Oh, really, how'd that go?" "I opened Initializer and > added a starter and copied how to pop the queue > and put the queue name in a file, then I added it > to git and it went into the CICD pipeline and now > it's in Prod." "Great." "It only even needs 1 gigabyte of RAM." > > Surely when it's like, "the only time this framework app > uses 1 gigabyte of RAM is at boot time it totally templates > itself into a gigabyte of RAM", then the guy's like "see, > I'm totally not using RAM." Yet it's like, "well, yeah, > but the meter for the RAM you're not using is on". > > > > At least then for re-routines, and if it helps it's quite > an idee fixe at this point, it's clear as described they can > be implemented in most languages with or without > threads as with just a minimum of threads and thread > locals and exception handling being well-defined and > the most usual sort of procedural call stack, then, > get this: taking plain usual code, giving it a ton of > threads, making every invocation one of these things, > and automatically parallelizing the code automatically > according to the flow-graph dependencies declared > in the synchronous, blocking, routine. > > Now _that's_ ridiculous. > > Though, in C++ with this sort of approach, the only > sort of "unusable" object is a future<result<T, E>> > as it were, or "the ubiquitous type" sort of thing > then as to overload its access as to invoke "get()", > if there was a sort of way to overload the "." and "->" > operators, and have them most simply be compiled > as invoke "." and "->". Does std::identity work this way? > > > > I read there's some C++ proposals to make for overloading the "." operator in C++ 20, then though I'd still wonder how to essentially make a wrapper class that dispatches all its accesses to, ..., functions, or as with regards to run-time-type-identification, with regards to making a future<result<T, E>> that is indistinguishable to auto or is a correct type according to the various rvalues the assignable lvalue, that otherwise passes everything through "." as through ".get()." and as through "->" as through "->get().", as for something like an "experimental:hidden_future<T, E>" as then for an "experimental:unusable<T>" for re-routines, unobtrusively otherwise in the language. In C it would sort of be according to whatever defines the struct or context or what's usually otherwise a class, for "idiomatic_boxed" then as for having "include offsets" to these types, then as with regards to C language support as via setjmp/longjmp I suppose or other notions that effect stack-unwinding as with handler blocks. For re-routines, .... It's like when you're writing a react app, and it's just a JavaScript that includes a file, so if you make enough of a model of browser-dom, not rendering and the whole bit but just browser-dom, then implement, "the algorithm", with the usual idea of a unidirectional single-page app, then it can have its units tests all figured out from just pointing to a different include file with otherwise matching the interface. Then there were added fibers and hooks and this kind of thing, if at all complicating the, "algorithm", all courtesy browser-dom, and UI events, and my favorite, form events. I don't have one of those but there's something to be said that just implementing in-memory what effects is its world
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-03 10:34 +0200 |
| Message-ID | <v127i4$ej9d$1@dont-email.me> |
| In reply to | #118994 |
On 03/05/2024 01:58, Chris M. Thomasson wrote: > On 5/2/2024 4:15 PM, Lawrence D'Oliveiro wrote: >> On Thu, 2 May 2024 13:28:15 -0700, Chris M. Thomasson wrote: >> >>> On 5/1/2024 10:39 PM, Lawrence D'Oliveiro wrote: >>>> >>>> On Wed, 1 May 2024 22:20:47 -0700, Chris M. Thomasson wrote: >>>> >>>>> On 5/1/2024 1:34 PM, Lawrence D'Oliveiro wrote: >>>>> >>>>>> Remember, we’re talking about maximizing I/O throughput here, so CPU >>>>>> is not the bottleneck. >>>>> >>>>> It can be if your thread synchronization scheme is sub par. >>>> >>>> Another reason to avoid threads. >>> >>> Why? Believe it or not, there are ways to create _highly_ scalable >>> thread synchronization schemes. >> >> I’m sure there are. But none of that is relevant when the CPU isn’t the >> bottleneck anyway. > > The CPU can become a bottleneck. Depends on how the programmer > implements things. > > >>>> So long as your async tasks have an await call somewhere in their main >>>> loops, that should be sufficient to avoid most bottlenecks. >>> >>> async tasks are using threads... No? >> >> No. They are built on coroutines. Specifically, the “stackless” variety. >> >> <https://gitlab.com/ldo/python_topics_notebooks/-/blob/master/Generators%20&%20Coroutines.ipynb?ref_type=heads> > > So, there is no way to take advantage of multiple threads on Python? > Heck, even JavaScript has WebWorkers... ;^) Python supports multi-threading. It uses a global lock (the "GIL") in the Python interpreter - thus only one thread can be running Python code at a time. However, if you are doing anything serious with Python, much of the time will be spend either blocked (waiting for network, IO, etc.) or using compiled or external code (using your favourite gui toolkit, doing maths with numpy, etc.). The GIL is released while executing such code. Thus if you are using Python for cpu-intensive work (and doing so sensibly), you have full multi-threading. If you are using it for IO-intensive work, you have full multi-threading. It's not going to be as efficient as well-written compiled code, even with JIT and pypy, but in practice it gets pretty close while being very convenient and developer friendly. If you really need parallel running of Python code, or better separation between tasks, Python has a multi-processing module that makes it simple to control and pass data between separate Python processes, each with their own GIL.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-03 18:05 +0300 |
| Message-ID | <20240503180533.000017ff@yahoo.com> |
| In reply to | #119008 |
On Fri, 3 May 2024 10:34:11 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 03/05/2024 01:58, Chris M. Thomasson wrote: > > On 5/2/2024 4:15 PM, Lawrence D'Oliveiro wrote: > >> On Thu, 2 May 2024 13:28:15 -0700, Chris M. Thomasson wrote: > >> > >>> On 5/1/2024 10:39 PM, Lawrence D'Oliveiro wrote: > >>>> > >>>> On Wed, 1 May 2024 22:20:47 -0700, Chris M. Thomasson wrote: > >>>> > >>>>> On 5/1/2024 1:34 PM, Lawrence D'Oliveiro wrote: > >>>>> > >>>>>> Remember, we’re talking about maximizing I/O throughput here, > >>>>>> so CPU is not the bottleneck. > >>>>> > >>>>> It can be if your thread synchronization scheme is sub par. > >>>> > >>>> Another reason to avoid threads. > >>> > >>> Why? Believe it or not, there are ways to create _highly_ scalable > >>> thread synchronization schemes. > >> > >> I’m sure there are. But none of that is relevant when the CPU > >> isn’t the bottleneck anyway. > > > > The CPU can become a bottleneck. Depends on how the programmer > > implements things. > > > > > >>>> So long as your async tasks have an await call somewhere in > >>>> their main loops, that should be sufficient to avoid most > >>>> bottlenecks. > >>> > >>> async tasks are using threads... No? > >> > >> No. They are built on coroutines. Specifically, the “stackless” > >> variety. > >> > >> <https://gitlab.com/ldo/python_topics_notebooks/-/blob/master/Generators%20&%20Coroutines.ipynb?ref_type=heads> > >> > > > > So, there is no way to take advantage of multiple threads on > > Python? Heck, even JavaScript has WebWorkers... ;^) > > Python supports multi-threading. It uses a global lock (the "GIL") > in the Python interpreter - thus only one thread can be running > Python code at a time. However, if you are doing anything serious > with Python, much of the time will be spend either blocked (waiting > for network, IO, etc.) or using compiled or external code (using your > favourite gui toolkit, doing maths with numpy, etc.). The GIL is > released while executing such code. > > Thus if you are using Python for cpu-intensive work (and doing so > sensibly), you have full multi-threading. If you are using it for > IO-intensive work, you have full multi-threading. It's not going to > be as efficient as well-written compiled code, even with JIT and > pypy, but in practice it gets pretty close while being very > convenient and developer friendly. > > If you really need parallel running of Python code, or better > separation between tasks, Python has a multi-processing module that > makes it simple to control and pass data between separate Python > processes, each with their own GIL. > > > A typical scenario is that you started you python program while thinking that it wouldn't e CPU-intensive. And then it grew and became CPU-intensive. That's actually a good case, because it means that your program is used and is doing something worthwhile.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-03 17:20 +0200 |
| Message-ID | <v12vb0$ju1r$2@raubtier-asyl.eternal-september.org> |
| In reply to | #119017 |
Am 03.05.2024 um 17:05 schrieb Michael S: > A typical scenario is that you started you python program while > thinking that it wouldn't e CPU-intensive. And then it grew and became > CPU-intensive. > That's actually a good case, because it means that your program is used > and is doing something worthwhile. I don't think it makes a big difference if Python has a GIL or not since it is interpreted and extremely slow with that anyway.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-03 18:47 +0300 |
| Message-ID | <20240503184754.00006997@yahoo.com> |
| In reply to | #119020 |
On Fri, 3 May 2024 17:20:00 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 03.05.2024 um 17:05 schrieb Michael S: > > > A typical scenario is that you started you python program while > > thinking that it wouldn't e CPU-intensive. And then it grew and > > became CPU-intensive. > > That's actually a good case, because it means that your program is > > used and is doing something worthwhile. > > I don't think it makes a big difference if Python has a GIL or > not since it is interpreted and extremely slow with that anyway. > 64 times faster than slow wouldn't be fast, but could be acceptable. And 64 HW threads nowadays is almost low-end server, I have one at work, just in case. Also, I don't see why in the future Python could not be JITted. Javascript was also considered slow 15-20 years ago, now it's pretty fast. But then, my knowledge of Python is very shallow, Possibly, it's not JITted yet because of fundamental reasons rather than due to lack of demand.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-05-03 22:19 +0000 |
| Message-ID | <v13ntf$p9ih$3@dont-email.me> |
| In reply to | #119023 |
On Fri, 3 May 2024 18:47:54 +0300, Michael S wrote: > Also, I don't see why in the future Python could not be JITted. It might require more use of static type annotations. Which some are adopting in their Python code.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-05-04 00:27 +0100 |
| Message-ID | <v13rto$q5b4$1@dont-email.me> |
| In reply to | #119023 |
On 03/05/2024 16:47, Michael S wrote: > On Fri, 3 May 2024 17:20:00 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Am 03.05.2024 um 17:05 schrieb Michael S: >> >>> A typical scenario is that you started you python program while >>> thinking that it wouldn't e CPU-intensive. And then it grew and >>> became CPU-intensive. >>> That's actually a good case, because it means that your program is >>> used and is doing something worthwhile. >> >> I don't think it makes a big difference if Python has a GIL or >> not since it is interpreted and extremely slow with that anyway. >> > > 64 times faster than slow wouldn't be fast, but could be acceptable. > And 64 HW threads nowadays is almost low-end server, I have one at > work, just in case. > Also, I don't see why in the future Python could not be JITted. > Javascript was also considered slow 15-20 years ago, now it's pretty > fast. > But then, my knowledge of Python is very shallow, Possibly, it's not > JITted yet because of fundamental reasons rather than due to lack of > demand. > PyPy has been around for many years.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-04 22:04 +0300 |
| Message-ID | <20240504220437.00002b91@yahoo.com> |
| In reply to | #119029 |
On Sat, 4 May 2024 00:27:53 +0100 bart <bc@freeuk.com> wrote: > On 03/05/2024 16:47, Michael S wrote: > > On Fri, 3 May 2024 17:20:00 +0200 > > Bonita Montero <Bonita.Montero@gmail.com> wrote: > > > >> Am 03.05.2024 um 17:05 schrieb Michael S: > >> > >>> A typical scenario is that you started you python program while > >>> thinking that it wouldn't e CPU-intensive. And then it grew and > >>> became CPU-intensive. > >>> That's actually a good case, because it means that your program is > >>> used and is doing something worthwhile. > >> > >> I don't think it makes a big difference if Python has a GIL or > >> not since it is interpreted and extremely slow with that anyway. > >> > > > > 64 times faster than slow wouldn't be fast, but could be acceptable. > > And 64 HW threads nowadays is almost low-end server, I have one at > > work, just in case. > > Also, I don't see why in the future Python could not be JITted. > > Javascript was also considered slow 15-20 years ago, now it's pretty > > fast. > > But then, my knowledge of Python is very shallow, Possibly, it's not > > JITted yet because of fundamental reasons rather than due to lack of > > demand. > > > > PyPy has been around for many years. I see. So, why PyPy didn't replace interpreter as a default engine?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-05-05 14:56 +0200 |
| Message-ID | <v17vm9$1s1vi$1@dont-email.me> |
| In reply to | #119054 |
On 04/05/2024 21:04, Michael S wrote: > On Sat, 4 May 2024 00:27:53 +0100 > bart <bc@freeuk.com> wrote: > >> On 03/05/2024 16:47, Michael S wrote: >>> On Fri, 3 May 2024 17:20:00 +0200 >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> >>>> Am 03.05.2024 um 17:05 schrieb Michael S: >>>> >>>>> A typical scenario is that you started you python program while >>>>> thinking that it wouldn't e CPU-intensive. And then it grew and >>>>> became CPU-intensive. >>>>> That's actually a good case, because it means that your program is >>>>> used and is doing something worthwhile. >>>> >>>> I don't think it makes a big difference if Python has a GIL or >>>> not since it is interpreted and extremely slow with that anyway. >>>> >>> >>> 64 times faster than slow wouldn't be fast, but could be acceptable. >>> And 64 HW threads nowadays is almost low-end server, I have one at >>> work, just in case. >>> Also, I don't see why in the future Python could not be JITted. >>> Javascript was also considered slow 15-20 years ago, now it's pretty >>> fast. >>> But then, my knowledge of Python is very shallow, Possibly, it's not >>> JITted yet because of fundamental reasons rather than due to lack of >>> demand. >>> >> >> PyPy has been around for many years. > > I see. > So, why PyPy didn't replace interpreter as a default engine? > There are different Python implementations, useful for different situations. JIT is helpful if you need high performance running code and are happy to pay the time and memory resources (often very large) for doing the compilation. But often you don't need high performance, at least not from the Python code itself, and JIT is just a waste.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-05-04 17:36 +0200 |
| Message-ID | <v15kla$199l7$1@raubtier-asyl.eternal-september.org> |
| In reply to | #119023 |
Am 03.05.2024 um 17:47 schrieb Michael S: >> I don't think it makes a big difference if Python has a GIL or >> not since it is interpreted and extremely slow with that anyway. > 64 times faster than slow wouldn't be fast, but could be acceptable. > ... With a GIL the code doesn't scale.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-05-04 22:11 +0300 |
| Message-ID | <20240504221102.00002461@yahoo.com> |
| In reply to | #119049 |
On Sat, 4 May 2024 17:36:12 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 03.05.2024 um 17:47 schrieb Michael S: > > >> I don't think it makes a big difference if Python has a GIL or > >> not since it is interpreted and extremely slow with that anyway. > > > 64 times faster than slow wouldn't be fast, but could be acceptable. > > ... > > With a GIL the code doesn't scale. > So, do you take back what you said just one post above?
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web