Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #91263 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-08-16 15:37 +0200 |
| Last post | 2023-08-30 19:02 +0200 |
| Articles | 20 on this page of 146 — 13 participants |
Back to article view | Back to comp.lang.c++
Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-16 15:37 +0200
Re: Sieve of Eratosthenes wij <wyniijj5@gmail.com> - 2023-08-16 10:57 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-16 20:21 +0200
Re: Sieve of Eratosthenes wij <wyniijj5@gmail.com> - 2023-08-16 12:17 -0700
Re: Sieve of Eratosthenes Paavo Helde <eesnimi@osa.pri.ee> - 2023-08-16 21:44 +0300
Re: Sieve of Eratosthenes wij <wyniijj5@gmail.com> - 2023-08-16 12:09 -0700
Re: Sieve of Eratosthenes "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-08-16 23:17 +0200
Re: Sieve of Eratosthenes "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-08-16 23:21 +0200
Re: Sieve of Eratosthenes "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-08-16 23:39 +0200
Re: Sieve of Eratosthenes "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-08-16 23:59 +0200
Re: Sieve of Eratosthenes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-16 16:27 -0700
Re: Sieve of Eratosthenes red floyd <no.spam.here@its.invalid> - 2023-08-16 18:06 -0700
Re: Sieve of Eratosthenes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-16 19:26 -0700
Re: Sieve of Eratosthenes Öö Tiib <ootiib@hot.ee> - 2023-08-27 12:26 -0700
Re: Sieve of Eratosthenes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-28 00:49 +0100
Re: Sieve of Eratosthenes Öö Tiib <ootiib@hot.ee> - 2023-08-27 23:23 -0700
Re: Sieve of Eratosthenes "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-08-28 15:53 +0200
Re: Sieve of Eratosthenes Öö Tiib <ootiib@hot.ee> - 2023-08-28 09:03 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-28 18:47 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-30 13:01 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-30 15:38 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-30 18:31 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-31 08:22 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-31 11:00 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-31 15:23 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-31 17:28 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-31 11:52 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-31 15:22 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-31 17:32 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-31 15:44 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-31 17:50 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-09-01 10:26 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 12:59 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-09-01 12:30 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 15:33 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-09-01 13:49 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 15:59 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-09-01 14:03 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 16:15 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-09-01 14:39 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 16:59 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-09-01 15:01 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 17:05 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-09-01 15:08 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 17:15 +0200
Re: Sieve of Eratosthenes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-31 21:33 +0100
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 05:35 +0200
Re: Sieve of Eratosthenes scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 14:43 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-31 16:57 +0200
Re: Sieve of Eratosthenes scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 16:10 +0000
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-31 15:25 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-31 17:33 +0200
Re: Sieve of Eratosthenes scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 16:12 +0000
Re: Sieve of Eratosthenes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-28 23:08 +0100
Re: Sieve of Eratosthenes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 15:15 -0700
Re: Sieve of Eratosthenes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-28 23:41 +0100
Re: Sieve of Eratosthenes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-30 17:45 -0700
Re: Sieve of Eratosthenes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-31 03:18 +0100
Re: Sieve of Eratosthenes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 15:08 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-17 08:42 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-17 11:38 +0200
Re: Sieve of Eratosthenes "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-08-17 12:50 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-17 13:10 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-17 17:47 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-21 11:00 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-21 17:19 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-21 19:50 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-21 18:12 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-21 20:22 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-21 19:01 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 05:27 +0200
Re: Sieve of Eratosthenes Öö Tiib <ootiib@hot.ee> - 2023-08-21 23:25 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 11:23 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 11:59 +0200
Re: Sieve of Eratosthenes Öö Tiib <ootiib@hot.ee> - 2023-08-22 05:15 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 14:23 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-22 06:56 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 11:27 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 11:34 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-22 14:13 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 16:17 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-22 14:27 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 16:48 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-22 14:57 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 17:00 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-22 17:56 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 20:13 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-22 18:18 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-22 20:50 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 06:51 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 09:59 +0200
Re: Sieve of Eratosthenes Richard Damon <Richard@Damon-Family.org> - 2023-08-23 07:52 -0400
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 14:40 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 14:24 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 16:30 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 14:36 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 16:38 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 14:43 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 16:45 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 17:49 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 20:05 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-24 17:18 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-24 19:20 +0200
Re: Sieve of Eratosthenes Daniel <danielaparker@gmail.com> - 2023-08-23 11:13 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 20:17 +0200
Re: Sieve of Eratosthenes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-23 11:20 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 20:24 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-24 17:25 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-24 19:29 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-24 17:40 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-24 19:49 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-25 16:07 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-25 18:10 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-25 16:15 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-25 18:18 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-26 08:03 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-26 10:16 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-26 08:27 +0000
Re: Sieve of Eratosthenes Daniel <danielaparker@gmail.com> - 2023-08-23 11:37 -0700
Re: Sieve of Eratosthenes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 15:33 -0700
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 14:20 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 16:32 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 14:41 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 16:47 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 17:51 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-23 20:09 +0200
Re: Sieve of Eratosthenes scott@slp53.sl.home (Scott Lurndal) - 2023-08-23 18:51 +0000
Re: Sieve of Eratosthenes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-24 11:25 -0700
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-24 17:22 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-24 19:27 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-24 17:37 +0000
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-24 19:52 +0200
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-25 16:07 +0000
Re: Sieve of Eratosthenes Daniel <danielaparker@gmail.com> - 2023-08-23 08:00 -0700
Re: Sieve of Eratosthenes scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 15:49 +0000
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-22 17:58 +0000
Re: Sieve of Eratosthenes scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 18:24 +0000
Re: Sieve of Eratosthenes Muttley@dastardlyhq.com - 2023-08-23 06:50 +0000
Re: Sieve of Eratosthenes wij <wyniijj5@gmail.com> - 2023-08-17 13:43 -0700
Re: Sieve of Eratosthenes "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-08-18 02:00 +0200
Re: Sieve of Eratosthenes wij <wyniijj5@gmail.com> - 2023-08-18 05:01 -0700
Re: Sieve of Eratosthenes wij <wyniijj5@gmail.com> - 2023-08-18 17:02 -0700
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-28 06:15 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-28 09:43 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-29 20:34 +0200
Re: Sieve of Eratosthenes Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-30 19:02 +0200
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-23 14:20 +0000 |
| Message-ID | <uc54jp$2v0bk$1@dont-email.me> |
| In reply to | #91358 |
On Wed, 23 Aug 2023 09:59:31 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 23.08.2023 um 08:51 schrieb Muttley@dastardlyhq.com: >> For stability? Seriously? > >Main memory has a latency from 20 - 30ns per access. My 1TB Samsung >PCIe 4.0 SSD has a synchronous latency of 32us, that's up to factor >1.800. Do you really think that a swappable application is usable ? >Swapping is just for low memory conditions so that the application >won't stop or crash. And low memory conditions can easily occur on machines running large databases if large query(s) are happening even with gigs of memory so swap space is still a thing. And thats not what I would call "stability" but I'm not going to get into an argument over word meanings. >> No, but I've got a Z80 C compiler that would happily compile and run it. > >I don't believe you. And no one is using Z-80s today. Believe what you like. Some TI calculators use Z80s FYI. Besides which a lot of 8 bit microcontrollers are LESS powerful than a Z80 and they still get programmed in C as well as assembler.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-08-23 16:32 +0200 |
| Message-ID | <uc559i$2v27t$2@dont-email.me> |
| In reply to | #91361 |
Am 23.08.2023 um 16:20 schrieb Muttley@dastardlyhq.com: > And low memory conditions can easily occur on machines running large > databases ... That's not true. If you have a database you chose the size of the buffer pool and the heaps in a way that the machine doesn't swap. Swapping is simply extremely uncommon. > Believe what you like. Some TI calculators use Z80s FYI. Prove that. > Besides which a lot of 8 bit microcontrollers are LESS powerful > than a Z80 and they still get programmed in C as well as assembler. Show me some of them.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-23 14:41 +0000 |
| Message-ID | <uc55r2$2v6us$1@dont-email.me> |
| In reply to | #91364 |
On Wed, 23 Aug 2023 16:32:19 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 23.08.2023 um 16:20 schrieb Muttley@dastardlyhq.com: > >> And low memory conditions can easily occur on machines running large >> databases ... > >That's not true. If you have a database you chose the size of the >buffer pool and the heaps in a way that the machine doesn't swap. >Swapping is simply extremely uncommon. Depends on the DB. If like Oracle its tablespaces are on bespoke disk partitions then it will do the equivalent of swapping if it needs to. >> Believe what you like. Some TI calculators use Z80s FYI. > >Prove that. You ever heard of google? Try "ti calculator z80". You never know what you might find. >> Besides which a lot of 8 bit microcontrollers are LESS powerful >> than a Z80 and they still get programmed in C as well as assembler. > >Show me some of them. FFS man, asre you a baby that needs to be spoon fed? Grow up! Google "8 bit PIC". We already had a "discussion" with you a while where you demonstrated your complete and utter pig ignorance of the embedded world. Perhaps don't make a fool of yourself again.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-08-23 16:47 +0200 |
| Message-ID | <uc566i$2v7nu$2@dont-email.me> |
| In reply to | #91367 |
Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com: > On Wed, 23 Aug 2023 16:32:19 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 23.08.2023 um 16:20 schrieb Muttley@dastardlyhq.com: >> >>> And low memory conditions can easily occur on machines running large >>> databases ... >> >> That's not true. If you have a database you chose the size of the >> buffer pool and the heaps in a way that the machine doesn't swap. >> Swapping is simply extremely uncommon. > > Depends on the DB. If like Oracle its tablespaces are on bespoke disk > partitions then it will do the equivalent of swapping if it needs to. The Oracle Data Warehousing Guide says that the performance advantage of raw partitions is between three and five percent. And you lose much comfort features like shnapshots. So no one actually uses raw partitions. And this feature has nothing to do with how you dimension your buffer pool or your heaps. > >>> Believe what you like. Some TI calculators use Z80s FYI. >> >> Prove that. > > You ever heard of google? Try "ti calculator z80". You never know what > you might find. LOL >>> Besides which a lot of 8 bit microcontrollers are LESS powerful >>> than a Z80 and they still get programmed in C as well as assembler. >> >> Show me some of them. > > FFS man, asre you a baby that needs to be spoon fed? Grow up! > Google "8 bit PIC". LOL > > We already had a "discussion" with you a while where you demonstrated your > complete and utter pig ignorance of the embedded world. Perhaps don't make > a fool of yourself again. > >
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-23 17:51 +0000 |
| Message-ID | <uc5gub$318b7$1@dont-email.me> |
| In reply to | #91370 |
On Wed, 23 Aug 2023 16:47:46 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com: >> Depends on the DB. If like Oracle its tablespaces are on bespoke disk >> partitions then it will do the equivalent of swapping if it needs to. > >The Oracle Data Warehousing Guide says that the performance >advantage of raw partitions is between three and five percent. >And you lose much comfort features like shnapshots. So no one >actually uses raw partitions. Oh right. You're an Oracle expert too now? :) >And this feature has nothing to do with how you dimension your >buffer pool or your heaps. Its a type of paging. >> FFS man, asre you a baby that needs to be spoon fed? Grow up! >> Google "8 bit PIC". > >LOL Get a grip aspie.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-08-23 20:09 +0200 |
| Message-ID | <uc5hvs$31g55$2@dont-email.me> |
| In reply to | #91374 |
Am 23.08.2023 um 19:51 schrieb Muttley@dastardlyhq.com: > On Wed, 23 Aug 2023 16:47:46 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com: >>> Depends on the DB. If like Oracle its tablespaces are on bespoke disk >>> partitions then it will do the equivalent of swapping if it needs to. >> >> The Oracle Data Warehousing Guide says that the performance >> advantage of raw partitions is between three and five percent. >> And you lose much comfort features like shnapshots. So no one >> actually uses raw partitions. > > Oh right. You're an Oracle expert too now? :) I have a OCP-DBA for Oracle 8i and I read that 20 years ago. I checked that in the current DWH-guide and they reverted that statement to five to ten percent. >> And this feature has nothing to do with how you dimension your >> buffer pool or your heaps. > Its a type of paging. Paging is synchronous, i.e. the thread which pages is stopped until the page is fetched. All modern database engines use asynchronous I/O, thereby issuing multiple requests and answering the responses often in a totally different order. And it's also not paging because this is explicitly issued by the database server, whereas real paging is a transparent memory access which isn't noticed by the application.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-23 18:51 +0000 |
| Message-ID | <fzsFM.617382$mPI2.355917@fx15.iad> |
| In reply to | #91376 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 23.08.2023 um 19:51 schrieb Muttley@dastardlyhq.com: >> On Wed, 23 Aug 2023 16:47:46 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com: >>>> Depends on the DB. If like Oracle its tablespaces are on bespoke disk >>>> partitions then it will do the equivalent of swapping if it needs to. >>> >>> The Oracle Data Warehousing Guide says that the performance >>> advantage of raw partitions is between three and five percent. >>> And you lose much comfort features like shnapshots. So no one >>> actually uses raw partitions. >> >> Oh right. You're an Oracle expert too now? :) > >I have a OCP-DBA for Oracle 8i and I read that 20 years ago. >I checked that in the current DWH-guide and they reverted >that statement to five to ten percent. > >>> And this feature has nothing to do with how you dimension your >>> buffer pool or your heaps. > >> Its a type of paging. > >Paging is synchronous, i.e. the thread which pages is stopped until >the page is fetched. Actually, sometimes the operating system will anticipate a future page fault and preload the page. Particularly on POSIX systems that support the madvise(2) or posix_madvise(2) system call(s).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-08-24 11:25 -0700 |
| Message-ID | <uc87bm$3iu02$2@dont-email.me> |
| In reply to | #91382 |
On 8/23/2023 11:51 AM, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 23.08.2023 um 19:51 schrieb Muttley@dastardlyhq.com: >>> On Wed, 23 Aug 2023 16:47:46 +0200 >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com: >>>>> Depends on the DB. If like Oracle its tablespaces are on bespoke disk >>>>> partitions then it will do the equivalent of swapping if it needs to. >>>> >>>> The Oracle Data Warehousing Guide says that the performance >>>> advantage of raw partitions is between three and five percent. >>>> And you lose much comfort features like shnapshots. So no one >>>> actually uses raw partitions. >>> >>> Oh right. You're an Oracle expert too now? :) >> >> I have a OCP-DBA for Oracle 8i and I read that 20 years ago. >> I checked that in the current DWH-guide and they reverted >> that statement to five to ten percent. >> >>>> And this feature has nothing to do with how you dimension your >>>> buffer pool or your heaps. >> >>> Its a type of paging. >> >> Paging is synchronous, i.e. the thread which pages is stopped until >> the page is fetched. > > Actually, sometimes the operating system will anticipate a future > page fault and preload the page. Particularly on POSIX systems > that support the madvise(2) or posix_madvise(2) system call(s). Yup. Cacheline prefetch can be damn good as well, in certain scenarios...
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-24 17:22 +0000 |
| Message-ID | <uc83kf$3i8rj$1@dont-email.me> |
| In reply to | #91376 |
On Wed, 23 Aug 2023 20:09:01 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 23.08.2023 um 19:51 schrieb Muttley@dastardlyhq.com: >> On Wed, 23 Aug 2023 16:47:46 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 23.08.2023 um 16:41 schrieb Muttley@dastardlyhq.com: >>>> Depends on the DB. If like Oracle its tablespaces are on bespoke disk >>>> partitions then it will do the equivalent of swapping if it needs to. >>> >>> The Oracle Data Warehousing Guide says that the performance >>> advantage of raw partitions is between three and five percent. >>> And you lose much comfort features like shnapshots. So no one >>> actually uses raw partitions. >> >> Oh right. You're an Oracle expert too now? :) > >I have a OCP-DBA for Oracle 8i and I read that 20 years ago. Does that on your wall alongside your Microsoft Certified Muppet certificates? >> Its a type of paging. > >Paging is synchronous, i.e. the thread which pages is stopped until >the page is fetched. All modern database engines use asynchronous >I/O, thereby issuing multiple requests and answering the responses >often in a totally different order. Until the data can be loaded from disk a query - even a highly parallelised one - will be partially or fully stalled however the I/O is done. >And it's also not paging because this is explicitly issued by the >database server, whereas real paging is a transparent memory access >which isn't noticed by the application. You think programs using SQL are aware of the database fetching and saving to disk?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-08-24 19:27 +0200 |
| Message-ID | <uc83tr$3i9b0$1@dont-email.me> |
| In reply to | #91391 |
Am 24.08.2023 um 19:22 schrieb Muttley@dastardlyhq.com: >> Paging is synchronous, i.e. the thread which pages is stopped until >> the page is fetched. All modern database engines use asynchronous >> I/O, thereby issuing multiple requests and answering the responses >> often in a totally different order. > Until the data can be loaded from disk a query - even a highly parallelised > one - will be partially or fully stalled however the I/O is done. I wanted to explain why this isn't paging. You don't underdtand the difference. >> And it's also not paging because this is explicitly issued by the >> database server, whereas real paging is a transparent memory access >> which isn't noticed by the application. > You think programs using SQL are aware of the database fetching and > saving to disk? What does this have to do with the discussion of paging vs. asynchronous I/O through a database server?
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-24 17:37 +0000 |
| Message-ID | <uc84ge$3iduk$1@dont-email.me> |
| In reply to | #91393 |
On Thu, 24 Aug 2023 19:27:25 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 24.08.2023 um 19:22 schrieb Muttley@dastardlyhq.com: > >>> Paging is synchronous, i.e. the thread which pages is stopped until >>> the page is fetched. All modern database engines use asynchronous >>> I/O, thereby issuing multiple requests and answering the responses >>> often in a totally different order. > >> Until the data can be loaded from disk a query - even a highly parallelised >> one - will be partially or fully stalled however the I/O is done. > >I wanted to explain why this isn't paging. >You don't underdtand the difference. They're analogous, not identical , but close enough. Both involve loading data into memory and saving it out to disk before the operation can proceed and in the case of ACID DBMSs the transaction data MUST be written to disk before the operation can complete. But I'm sure you know all this, right? >>> And it's also not paging because this is explicitly issued by the >>> database server, whereas real paging is a transparent memory access >>> which isn't noticed by the application. > >> You think programs using SQL are aware of the database fetching and >> saving to disk? > >What does this have to do with the discussion of >paging vs. asynchronous I/O through a database server? FFS , are you even aware of what you wrote?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-08-24 19:52 +0200 |
| Message-ID | <uc85c9$3ihua$2@dont-email.me> |
| In reply to | #91395 |
Am 24.08.2023 um 19:37 schrieb Muttley@dastardlyhq.com: > On Thu, 24 Aug 2023 19:27:25 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 24.08.2023 um 19:22 schrieb Muttley@dastardlyhq.com: >> >>>> Paging is synchronous, i.e. the thread which pages is stopped until >>>> the page is fetched. All modern database engines use asynchronous >>>> I/O, thereby issuing multiple requests and answering the responses >>>> often in a totally different order. >> >>> Until the data can be loaded from disk a query - even a highly parallelised >>> one - will be partially or fully stalled however the I/O is done. >> >> I wanted to explain why this isn't paging. >> You don't underdtand the difference. > > They're analogous, not identical , but close enough. Both involve loading > data into memory and saving it out to disk before the operation can proceed > and in the case of ACID DBMSs the transaction data MUST be written to disk > before the operation can complete. But that is a very superficial comparison. And there are no transactions in paging either.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-25 16:07 +0000 |
| Message-ID | <ucajkv$3nhe$1@dont-email.me> |
| In reply to | #91398 |
On Thu, 24 Aug 2023 19:52:10 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 24.08.2023 um 19:37 schrieb Muttley@dastardlyhq.com: >> They're analogous, not identical , but close enough. Both involve loading >> data into memory and saving it out to disk before the operation can proceed >> and in the case of ACID DBMSs the transaction data MUST be written to disk >> before the operation can complete. > >But that is a very superficial comparison. >And there are no transactions in paging either. *sigh* Forget it.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2023-08-23 08:00 -0700 |
| Message-ID | <6013a904-e08d-4ec0-950f-ca9889fdec39n@googlegroups.com> |
| In reply to | #91361 |
On Wednesday, August 23, 2023 at 10:20:59 AM UTC-4, Mut...@dastardlyhq.com wrote: > And low memory conditions can easily occur on machines running large databases > if large query(s) are happening even with gigs of memory so swap space is still > a thing. > When I started programming in the mid eighties, memory was a scarce resource, and one of my earliest lessons was that there were only three numbers that counted: zero, one, and as many as you like. Many years later, when memory was abundant, I found it astonishing that so many applications were nonperforming when processing large amounts of data. Few were designed to process "as many as you like", a great number, from desktop photo imaging software to multimillion dollar capital markets applications, were designed to load everything into memory, as if it were a zero cost resource. But large database queries need not translate to unbounded memory requirements, RDBMs have cursors, caching on the server, and other features to avoid it. Applications that swapped too much were generally poorly designed. Daniel
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-22 15:49 +0000 |
| Message-ID | <VN4FM.455991$U3w1.188926@fx09.iad> |
| In reply to | #91347 |
Muttley@dastardlyhq.com writes: >On Tue, 22 Aug 2023 16:48:45 +0200 >Bonita Montero <Bonita.Montero@gmail.com> wrote: >>Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com: >> >>> Accessing bits in a word is normally slower than accessing the whole word >>> on most CPUs. ... >> >>I have shown that when the amount of data is large enough, access time >>has the greatest weight. Furthermore, most of the calculations for the >>bits within the byte in other arithmetic units take place in parallel. > >CPUs only have 1 data bus no matter how many cores That is not an accurate statement for any processor built in the last decade or more. Most of them use a mesh, crossbar or ring structure, not a shared bus structure to interface the cores to the memory subsystem on the chip. Most have multiple DRAM controllers (from one at the real low end to twenty at the high end) and stripe the DRAM address space across the controllers. All CPUs have private L1 and L2 caches, and large shared LLC caches (LLC is distributed across mesh elements) whic signifinctly reduce DRAM controller accesses. Likewise, on the I/O side, there are multiple bridges from the mesh/ring structures into the I/O side (e.g. one host bridge per PCI Express root port, one or more for on-chip accelerators, etc).
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-22 17:58 +0000 |
| Message-ID | <uc2t0t$2gsa4$1@dont-email.me> |
| In reply to | #91349 |
On Tue, 22 Aug 2023 15:49:09 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >Muttley@dastardlyhq.com writes: >>On Tue, 22 Aug 2023 16:48:45 +0200 >>Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com: >>> >>>> Accessing bits in a word is normally slower than accessing the whole word >>>> on most CPUs. ... >>> >>>I have shown that when the amount of data is large enough, access time >>>has the greatest weight. Furthermore, most of the calculations for the >>>bits within the byte in other arithmetic units take place in parallel. >> >>CPUs only have 1 data bus no matter how many cores > >That is not an accurate statement for any processor built in >the last decade or more. Most of them use a mesh, crossbar or ring Given millions of 8 and 16 bit processors are still designed and produced for embedded systems that statement is nonsense and ARM based systems can use whatever parts they want in the CPU. >structure, not >a shared bus structure to interface the cores to the memory subsystem on the >chip. Most have multiple DRAM controllers (from one at >the real low end to twenty at the high end) and stripe >the DRAM address space across the controllers. All CPUs have private >L1 and L2 caches, and large shared LLC caches (LLC is distributed >across mesh elements) whic signifinctly reduce DRAM controller accesses. > >Likewise, on the I/O side, there are multiple bridges from the >mesh/ring structures into the I/O side (e.g. one host bridge per >PCI Express root port, one or more for on-chip accelerators, etc). Thats nice, but CPU > x86.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-22 18:24 +0000 |
| Message-ID | <_37FM.570529$SuUf.449990@fx14.iad> |
| In reply to | #91351 |
Muttley@dastardlyhq.com writes: >On Tue, 22 Aug 2023 15:49:09 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: >>Muttley@dastardlyhq.com writes: >>>On Tue, 22 Aug 2023 16:48:45 +0200 >>>Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>Am 22.08.2023 um 16:27 schrieb Muttley@dastardlyhq.com: >>>> >>>>> Accessing bits in a word is normally slower than accessing the whole word >>>>> on most CPUs. ... >>>> >>>>I have shown that when the amount of data is large enough, access time >>>>has the greatest weight. Furthermore, most of the calculations for the >>>>bits within the byte in other arithmetic units take place in parallel. >>> >>>CPUs only have 1 data bus no matter how many cores >> >>That is not an accurate statement for any processor built in >>the last decade or more. Most of them use a mesh, crossbar or ring > >Given millions of 8 and 16 bit processors are still designed and produced for >embedded systems that statement is nonsense and ARM based systems can use >whatever parts they want in the CPU. ARM based multicore systems generally use CMN-400/500/600/700 IP (from ARM) as the processor interconnect. https://developer.arm.com/Processors/CoreLink%20CMN-600 And all those 8 and 16-bit processors are single core, so your statement above, which references "no matter how many cores" doesn't apply to them. > >>structure, not >>a shared bus structure to interface the cores to the memory subsystem on the >>chip. Most have multiple DRAM controllers (from one at >>the real low end to twenty at the high end) and stripe >>the DRAM address space across the controllers. All CPUs have private >>L1 and L2 caches, and large shared LLC caches (LLC is distributed >>across mesh elements) whic signifinctly reduce DRAM controller accesses. >> >>Likewise, on the I/O side, there are multiple bridges from the >>mesh/ring structures into the I/O side (e.g. one host bridge per >>PCI Express root port, one or more for on-chip accelerators, etc). > >Thats nice, but CPU > x86. What does that mean? Every major multicore processor currently shipping (including Apple M7+) operate as described above. Including most mid-range and high-end application specific system-on-chips (SoC), including those using the ARM architecture. The proceedings from https://hotchips.org/ over the last two decades describe the state of the art.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-08-23 06:50 +0000 |
| Message-ID | <uc4a7k$2qpu1$1@dont-email.me> |
| In reply to | #91354 |
On Tue, 22 Aug 2023 18:24:58 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >Muttley@dastardlyhq.com writes: >>>That is not an accurate statement for any processor built in >>>the last decade or more. Most of them use a mesh, crossbar or ring >> >>Given millions of 8 and 16 bit processors are still designed and produced for > >>embedded systems that statement is nonsense and ARM based systems can use >>whatever parts they want in the CPU. > >ARM based multicore systems generally use CMN-400/500/600/700 IP (from ARM) >as the processor interconnect. > >https://developer.arm.com/Processors/CoreLink%20CMN-600 > >And all those 8 and 16-bit processors are single core, so your >statement above, which references "no matter how many cores" >doesn't apply to them. You said any processor built in the last decade or more. You didn't specific only multicore. Do you wish to retract that statement?
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2023-08-17 13:43 -0700 |
| Message-ID | <32ea0325-fd1f-4328-8a77-06705ad9c689n@googlegroups.com> |
| In reply to | #91271 |
On Thursday, August 17, 2023 at 5:17:54 AM UTC+8, Alf P. Steinbach wrote:
> On 2023-08-16 3:37 PM, Bonita Montero wrote:
> > I tried to implement the sieve of Erastosthenes as fast as possible.
> > I didn't thought it would make a big difference, but having a bit-wise
> > vector<bool> instead of a vector<char> makes the code twice as fast
> > for my AMD 7950X PC and an upper bound of one billion. The additional
> > overhead for the bit-wise access is less than the additional overhead
> > of fetching more memory.
> An apparent mystery, because I get only a marginal difference, down at
> 10% or less.
>
> On my computer the code below is slightly faster than yours for a
> 10'000'000 sieve, respectively (typical results, three runs, only the
> vector allocation + sieve code measured, not file i/o)
>
> 0.0477802 seconds.
> 0.0466974 seconds.
> 0.0472202 seconds.
>
> ... for my code, versus
>
> 0.0502888 seconds.
> 0.0482821 seconds.
> 0.0505414 seconds.
>
> ... for yours with the `std::string_view` instantiations fixed,
> producing the same file contents.
>
>
> #include <fmt/core.h>
> #include "cppm-Timer.hpp"
>
> #include <vector>
> using std::ofstream,
> std::vector;
>
> #include <stdlib.h> // EXIT_FAILURE
> #include <stdio.h> // fopen, fclose
>
> auto main() -> int
> {
> constexpr int n = 10'000'000;
>
> cppm::Timer timer;
> auto is_composite = vector<bool>( n + 1 );
> for( int i = 2; i < n; ) {
> while( is_composite[i] ) { ++i; }
> const int prime = i;
> for( int j = 2*prime; j < n; j += prime ) { is_composite[j]
> = true; }
> ++i;
> }
> timer.stop();
> fmt::print( "{} seconds.\n", timer.seconds() );
>
> auto f = fopen( "primes.alf.txt", "w" );
> if( not f ) { return EXIT_FAILURE; }
> for( int i = 2; i < n; ++i ) {
> if( not is_composite[i] ) {
> fmt::print( f, "{:d}\n", i );
> }
> }
> fclose( f );
> }
>
>
> The timer code:
>
>
> #pragma once
>
> #include <chrono>
> #include <optional>
> #include <type_traits>
>
> namespace cppm {
> namespace chrono = std::chrono;
> using std::optional, // <optional>
> std::conditional_t; // <type_traits>
>
> using Duration = chrono::duration<double>;
>
> class Timer
> {
> using Hrc = chrono::high_resolution_clock; using Sc =
> chrono::steady_clock;
>
> public:
> using Clock = conditional_t<Hrc::is_steady, Hrc, Sc>;
> using Time_point = chrono::time_point<Clock>;
>
> private:
> Time_point m_start_time;
> optional<Time_point> m_opt_end_time;
>
> public:
> Timer(): m_start_time( Clock::now() ), m_opt_end_time() {}
>
> void stop() { if( not m_opt_end_time ) { m_opt_end_time =
> Clock::now(); } }
>
> auto duration() const -> Duration { return
> m_opt_end_time.value() - m_start_time; }
> auto seconds() const -> double { return
> duration().count(); }
> };
> } // namespace cppm
>
>
> I have some other more advanced prime sieve code that I made for an
> example, but I think it's much slower, it's just a way that can go on
> and on forever, or more precisely till the end of the integer type's
> range or it runs out of memory for a map of the deduces primes.
>
>
> - Alf
Code Comment:
1. The use of 'not' is impressive, bringing dead to life.
2. The creation of class Timer may be questionable. Or it is just specifically
to simply and emphasize the main codes.
3. I don't know what "fmt::print( f, "{:d}\n", i );" really mean, but in general
I think cstring format in its current usage (e.g. "foo %s= %d\n") does not
provide real benefit for the executing time spent interpreting it.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2023-08-18 02:00 +0200 |
| Message-ID | <ubmcas$3v0no$1@dont-email.me> |
| In reply to | #91289 |
On 2023-08-17 10:43 PM, wij wrote:
> On Thursday, August 17, 2023 at 5:17:54 AM UTC+8, Alf P. Steinbach wrote:
[snip]
>
> Code Comment:
> 1. The use of 'not' is impressive, bringing dead to life.
I guess that means you didn't like it, but I do.
It may be an acquired taste, like coffee and beer. And I came to C++
from Pascals and Modula-2 and such. But try it: you may come to like it.
> 2. The creation of class Timer may be questionable. Or it is just specifically
> to simply and emphasize the main codes.
Factoring out that functionality in a header makes it easy to reuse.
And it was reused.
But even with no hope of reuse you should not be afraid to define useful
abstractions, as opposed to just using others' abstractions.
> 3. I don't know what "fmt::print( f, "{:d}\n", i );" really mean, but in general
> I think cstring format in its current usage (e.g. "foo %s= %d\n") does not
> provide real benefit for the executing time spent interpreting it.
With the {fmt} library's `fmt::print`, which will become C++23's
`std::print`, the format string is interpreted at compile time.
That's almost like a lint implemented via C++ template system, plus that
it's just about the fastest string formatting around, plus handles
Unicode (guaranteed by the standard) if the output device can do it.
The design of the compile time format string handling does however not
adhere to the principle of least surprise, and that caused the
standard's wording to be a bit sabotage-like for some time. That was
eventually fixed. But means that somewhere I have this C++20 code:
#if __cpp_lib_format >= (2022*100 + 7)
#define myprefix_FMTLIB_API_PROVIDES_FORMAT_STRING_TYPE
constexpr bool api_provides_format_string_type = true;
- Alf
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web