Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #118653 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2024-04-04 20:11 +0200 |
| Last post | 2024-04-07 18:25 +0300 |
| Articles | 10 on this page of 90 — 10 participants |
Back to article view | Back to comp.lang.c++
Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-04 20:11 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-04 21:55 +0300
Re: Ain't that beautiful ? Sam <sam@email-scan.com> - 2024-04-04 20:00 -0400
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 00:21 +0000
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 17:44 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 17:27 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 18:37 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 18:04 +0200
Re: Ain't that beautiful ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-06 15:55 -0700
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 08:28 +0200
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 15:51 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:35 +0200
Re: Ain't that beautiful ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-07 12:21 -0700
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 05:05 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 17:52 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 17:26 +0200
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 20:00 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 22:29 +0200
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 21:29 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-06 09:06 +0200
Re: Ain't that beautiful ? Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-06 17:29 +0300
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-06 14:56 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-06 18:34 +0200
Re: Ain't that beautiful ? wij <wyniijj5@gmail.com> - 2024-04-07 03:00 +0800
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 08:28 +0200
Re: Ain't that beautiful ? wij <wyniijj5@gmail.com> - 2024-04-08 07:47 +0800
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 15:25 +0300
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 16:00 +0300
Re: Ain't that beautiful ? David Brown <david.brown@hesbynett.no> - 2024-04-07 16:06 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 18:37 +0300
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 15:58 +0000
Re: Ain't that beautiful ? David Brown <david.brown@hesbynett.no> - 2024-04-07 18:00 +0200
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:38 +0200
std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 18:38 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-07 18:06 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 19:35 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 11:29 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 13:34 +0300
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-08 19:18 +0800
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 16:32 +0300
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-09 08:40 +0800
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 12:48 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-09 13:16 +0200
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 15:30 +0200
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-08 17:19 +0000
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 00:47 +0300
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-08 23:00 +0000
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 02:20 +0300
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-09 15:22 +0000
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 09:11 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 13:12 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 15:01 +0200
Re: std::map advocacy Richard Damon <richard@damon-family.org> - 2024-04-08 07:10 -0400
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 15:45 +0200
Re: std::map advocacy James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-04-08 19:42 -0400
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 09:45 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 13:27 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 15:13 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 18:12 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 18:22 +0200
Re: std::map advocacy James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-04-10 02:24 -0400
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 00:07 +0300
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:18 +0300
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:39 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 16:21 +0200
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 15:31 +0200
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-11 22:40 +0800
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 16:55 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:13 +0300
Re: std::map advocacy Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-11 18:18 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 09:57 +0200
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 13:47 +0200
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 14:04 +0200
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-11 19:25 +0800
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 16:09 +0000
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 19:48 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:45 +0200
Re: std::map advocacy Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-08 16:37 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:44 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 11:15 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-08 14:09 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 16:26 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-08 16:54 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 20:52 +0300
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 00:17 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-09 07:34 +0200
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 16:39 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 18:41 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:36 +0200
Re: Ain't that beautiful ? Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-07 18:25 +0300
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-08 14:09 +0200 |
| Subject | Re: std::map advocacy |
| Message-ID | <uv0mps$3fsqc$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118698 |
Am 08.04.2024 um 10:15 schrieb Michael S: > What exactly is nonsense? > You are saying approximately the same that I said above. You said that a cusom implementation of a RB- or AVL-tree is multiple times faster. I said that this depends on the tree's properties because you've got pointer chasing with trees; and you can't improve that with a custom implementation. > On x86-64 with MSVC/gcc/clang each std::set/multiset node occupies 32 > bytes even when key is only 32 bits. ... There ar three pointers: to the parent and to the children and if a RB-tree is used there's a flag that determines the colour of the node. There's nothing to get around that.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-08 16:26 +0300 |
| Subject | Re: std::map advocacy |
| Message-ID | <20240408162634.00003670@yahoo.com> |
| In reply to | #118703 |
On Mon, 8 Apr 2024 14:09:32 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 08.04.2024 um 10:15 schrieb Michael S: > > > What exactly is nonsense? > > You are saying approximately the same that I said above. > > You said that a cusom implementation of a RB- or AVL-tree is multiple > times faster. I said that this depends on the tree's properties > because you've got pointer chasing with trees; and you can't improve > that with a custom implementation. > I never said what you think I said. In fact, I said an opposite - that bigger factors could happen only when competing structure/algorithm is *not* a balanced binary tree of any sort. > > On x86-64 with MSVC/gcc/clang each std::set/multiset node occupies > > 32 bytes even when key is only 32 bits. ... > > There ar three pointers: to the parent and to the children and if a > RB-tree is used there's a flag that determines the colour of the node. > There's nothing to get around that. There is little (not nothing, see below) to do about it under restrictions of std API. In the absence of restrictions several thing possible. Even under restrictions of std API, parent link is not strictly necessary. In absence of knowledge about expected usage, it's probably wise to have it. But when the usage is known there are cases where one would do better without it. Such cases are not even too rare. And if you wonder, no, I don't think that taken in isolation removal of parent link could provide measurable gain. It's just one example of what could be done when you are determined to shrink the size of the node.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-08 16:54 +0200 |
| Subject | Re: std::map advocacy |
| Message-ID | <uv10ea$3iatt$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118704 |
Am 08.04.2024 um 15:26 schrieb Michael S: > Even under restrictions of std API, parent link is not strictly > necessary. This would make iterators large since they's have to carry a stack ov parent nodes.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-08 20:52 +0300 |
| Subject | Re: std::map advocacy |
| Message-ID | <20240408205253.000020e3@yahoo.com> |
| In reply to | #118709 |
On Mon, 8 Apr 2024 16:54:02 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 08.04.2024 um 15:26 schrieb Michael S: > > > Even under restrictions of std API, parent link is not strictly > > necessary. > > This would make iterators large since they's have to carry a stack > ov parent nodes. > > For modifications, yes. But that's still only LogN, but in time and in size of temporary storage. And search from root which in majority of workloads is the most common operation by far, is not affected.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-09 00:17 +0300 |
| Subject | Re: std::map advocacy |
| Message-ID | <20240409001728.00004beb@yahoo.com> |
| In reply to | #118711 |
On Mon, 8 Apr 2024 20:52:53 +0300 Michael S <already5chosen@yahoo.com> wrote: > On Mon, 8 Apr 2024 16:54:02 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > > > Am 08.04.2024 um 15:26 schrieb Michael S: > > > > > Even under restrictions of std API, parent link is not strictly > > > necessary. > > > > This would make iterators large since they's have to carry a stack > > ov parent nodes. > > > > > > For modifications, yes. But that's still only LogN, but in time and in > size of temporary storage. And search from root which in majority of > workloads is the most common operation by far, is not affected. > I meant to write "both in time and etc..."
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-09 07:34 +0200 |
| Subject | Re: std::map advocacy |
| Message-ID | <uv2k22$1qe2$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118711 |
Am 08.04.2024 um 19:52 schrieb Michael S: > For modifications, yes. But that's still only LogN, but in time and > in size of temporary storage. And search from root which in majority > of workloads is the most common operation by far, is not affected. If you've got a large number of nodes this only would be a "problem" if an additional cacheline would be loaded for a node.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-07 16:39 +0200 |
| Message-ID | <uuub65$2r67g$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118677 |
Am 07.04.2024 um 15:00 schrieb Michael S: > $ gcc -c -Wall -O2 foo.cpp raii-foo.cpp > $ size *.o > text data bss dec hex filename > 136 0 0 136 88 foo.o > 172 0 0 172 ac raii-foo.o > That's because of the unrolling code for exceptions. But this unrolling code is separate and usually not executed. The code path for the non-exceptional case should have the same perfor- mance.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-07 18:41 +0300 |
| Message-ID | <20240407184156.00006d7b@yahoo.com> |
| In reply to | #118679 |
On Sun, 7 Apr 2024 16:39:02 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 07.04.2024 um 15:00 schrieb Michael S: > > > $ gcc -c -Wall -O2 foo.cpp raii-foo.cpp > > $ size *.o > > text data bss dec hex filename > > 136 0 0 136 88 foo.o > > 172 0 0 172 ac raii-foo.o > > > > That's because of the unrolling code for exceptions. But this > unrolling code is separate and usually not executed. The code > path for the non-exceptional case should have the same perfor- > mance. > Didn't I say it myself about low runtime cost?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-07 19:36 +0200 |
| Message-ID | <uuuli3$2tk05$2@raubtier-asyl.eternal-september.org> |
| In reply to | #118683 |
Am 07.04.2024 um 17:41 schrieb Michael S: > On Sun, 7 Apr 2024 16:39:02 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Am 07.04.2024 um 15:00 schrieb Michael S: >> >>> $ gcc -c -Wall -O2 foo.cpp raii-foo.cpp >>> $ size *.o >>> text data bss dec hex filename >>> 136 0 0 136 88 foo.o >>> 172 0 0 172 ac raii-foo.o >>> >> >> That's because of the unrolling code for exceptions. But this >> unrolling code is separate and usually not executed. The code >> path for the non-exceptional case should have the same perfor- >> mance. >> > > Didn't I say it myself about low runtime cost? > > I think there's no additional runtime cost over manual releases at all if no exception is thrown.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-04-07 18:25 +0300 |
| Message-ID | <uuudsl$2rrgv$1@dont-email.me> |
| In reply to | #118677 |
07.04.2024 16:00 Michael S kirjutas: > On Sat, 6 Apr 2024 17:29:45 +0300 > Paavo Helde <eesnimi@osa.pri.ee> wrote: >> >> run-time performance hits. But iostreams do not make up most of C++. >> >> Still, the best feature of C++ is RAII (zero run-time performance >> hit). >> > > RAII has low run-time cost, although I doubt that it's really zero. > RAII has non-trivial code size cost, esp. when used a lot. See below. The last time when I had to worry about code size was in year 1992, with an Intel 80186 processor. But I understand it might be a concern in some applications. > But my main objection with RAII is that I feel like loosing track. It's the opposite for me. I feel myself at ease and having control only after I put a resource release properly under RAII.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c++
csiph-web