Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67345 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-08-07 07:13 +0200 |
| Last post | 2019-08-08 17:14 +0200 |
| Articles | 20 on this page of 215 — 20 participants |
Back to article view | Back to comp.lang.c++
Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 07:13 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-06 23:20 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 08:57 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:22 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 09:26 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:33 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 09:52 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 13:37 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:14 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson " <ahh_f_it@crap.nothing> - 2019-08-08 00:00 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson " <ahh_f_it@crap.nothing> - 2019-08-07 23:59 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-08-17 22:13 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:35 -0700
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 14:47 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 16:55 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 15:11 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 17:41 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 15:58 +0000
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 00:24 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 10:07 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 20:55 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:03 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 23:54 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 08:57 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 22:42 -0700
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 14:46 +0000
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 14:09 -0700
Re: Performance of unaligned memory-accesses Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-07 11:00 +0300
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 10:03 +0200
Re: Performance of unaligned memory-accesses Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-07 11:46 +0300
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 11:19 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 13:13 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 13:29 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 14:02 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 14:08 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 15:57 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-07 12:37 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 14:47 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 16:18 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 16:53 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 17:30 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 17:39 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 18:12 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 18:33 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 21:32 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:01 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:48 +0200
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-07 23:02 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 07:43 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 22:54 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 08:04 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-08 00:16 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 09:58 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-08 01:20 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:47 +0200
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-08 10:29 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:50 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 17:05 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 17:33 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 09:56 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:51 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 17:10 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 17:35 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 17:38 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 21:45 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-08 20:00 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 06:52 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 07:59 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 09:19 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 09:32 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 10:14 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 10:21 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 13:01 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 13:09 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-09 15:38 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 15:45 +0200
Re: Performance of unaligned memory-accesses Robert Wessel <robertwessel2@yahoo.com> - 2019-08-09 09:37 -0500
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 16:59 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 17:04 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-09 16:43 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 19:18 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-09 23:28 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 08:55 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 17:21 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 17:25 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 23:32 +0200
Re: Performance of unaligned memory-accesses Ian Collins <ian-news@hotmail.com> - 2019-08-11 10:59 +1200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 02:24 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:53 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 17:26 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 19:18 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 23:00 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 23:44 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 23:46 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-12 01:02 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 09:15 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> - 2019-08-11 16:37 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> - 2019-08-11 16:42 -0700
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@example.com> - 2019-08-11 22:05 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:25 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:24 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:22 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:23 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 17:10 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 17:21 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 17:31 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 23:47 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:40 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:27 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-10 23:46 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-10 23:22 +0100
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-10 16:11 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-10 17:32 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 15:41 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 15:55 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 18:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 18:15 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 18:59 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 19:03 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 23:48 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 00:15 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-12 01:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 09:13 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-12 13:32 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 13:40 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 11:44 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 14:30 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 13:09 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 15:14 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 19:13 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 21:15 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-12 19:25 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-13 02:28 +0200
Re: Performance of unaligned memory-accesses Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-13 01:08 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-13 16:03 +0200
Re: Performance of unaligned memory-accesses Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-14 09:27 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-14 20:51 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-14 13:14 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-14 15:04 -0700
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-14 15:47 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-15 10:15 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 07:11 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-14 23:37 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 09:25 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-15 03:41 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 14:25 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-15 16:06 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-15 16:21 +0200
Re: Performance of unaligned memory-accesses Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-15 16:56 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-16 06:44 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-14 16:53 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 18:40 +0200
Re: Performance of unaligned memory-accesses Ralf Goertz <me@myprovider.invalid> - 2019-08-13 08:53 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-13 09:18 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-11 19:00 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 21:06 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-11 13:07 -0700
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-11 23:58 +0100
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-11 17:07 -0700
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-12 10:14 +0100
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 11:30 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 13:03 +0200
Re: Performance of unaligned memory-accesses Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-12 13:06 +0100
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-12 10:34 +0100
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-12 08:49 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 18:10 +0200
Re: Performance of unaligned memory-accesses Öö Tiib <ootiib@hot.ee> - 2019-08-12 09:22 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-12 18:24 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-12 16:38 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-12 09:33 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-11 13:11 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 23:59 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-10 19:31 -0400
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-11 15:52 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-11 07:28 +0200
Re: Performance of unaligned memory-accesses James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-08-10 16:37 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-09 21:35 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 21:43 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-08 12:51 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:55 +0200
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 16:57 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 16:07 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 18:38 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 17:34 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 20:07 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 20:16 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:42 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 21:19 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 23:40 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-07 19:58 +0000
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-07 22:08 +0200
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 22:13 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-21 20:26 +0000
Re: Performance of unaligned memory-accesses Christopher Collins <ccollins476ad@gmail.com> - 2019-08-07 12:50 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-07 22:18 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-07 22:52 +0100
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 17:52 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 10:39 +0200
Re: Performance of unaligned memory-accesses Bart <bc@freeuk.com> - 2019-08-08 13:48 +0100
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 15:53 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 17:27 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 10:43 +0200
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-08 13:33 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 23:34 +0200
Re: Performance of unaligned memory-accesses Christopher Collins <ccollins476ad@gmail.com> - 2019-08-07 17:28 -0700
Re: Performance of unaligned memory-accesses Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-08 09:30 +0200
Re: Performance of unaligned memory-accesses "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-07 14:20 -0700
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 17:27 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 11:39 +0200
Re: Performance of unaligned memory-accesses Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-07 19:48 +0000
Re: Performance of unaligned memory-accesses Keith Thompson <kst-u@mib.org> - 2019-08-07 15:51 -0700
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 12:51 +0200
Re: Performance of unaligned memory-accesses scott@slp53.sl.home (Scott Lurndal) - 2019-08-08 14:46 +0000
Re: Performance of unaligned memory-accesses David Brown <david.brown@hesbynett.no> - 2019-08-08 17:14 +0200
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-08-12 10:14 +0100 |
| Message-ID | <20190812101429.b08ffb56aeaea0141cb62b9f@cvine--nospam--.freeserve.co.uk> |
| In reply to | #67584 |
On Sun, 11 Aug 2019 17:07:21 -0700 Keith Thompson <kst-u@mib.org> wrote: [snip] > And since x64 can access words at odd addresses, there's no problem. > > If you wanted to target your compiler to systems that don't support > accessing words at odd addresses, you might have a problem. Even with compiler systems that do support accessing words at odd addresses, there is a potential problem in a multi-threaded program. The guarantee that, in updating one scalar, the computer cannot alter an adjacent scalar and then restore it (that is, it cannot interfere with scalars in use by another thread) may no longer apply. The program may no longer be thread safe.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-12 11:30 +0200 |
| Message-ID | <qirbjt$k2n$1@news.albasani.net> |
| In reply to | #67588 |
> Even with compiler systems that do support accessing words at odd > addresses, there is a potential problem in a multi-threaded program. > The guarantee that, in updating one scalar, the computer cannot alter > an adjacent scalar and then restore it (that is, it cannot interfere > with scalars in use by another thread) may no longer apply. The program > may no longer be thread safe. That might also be implementation-dependent.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-12 13:03 +0200 |
| Message-ID | <qirh25$59s$1@news.albasani.net> |
| In reply to | #67589 |
>> Even with compiler systems that do support accessing words at odd
>> addresses, there is a potential problem in a multi-threaded program.
>> The guarantee that, in updating one scalar, the computer cannot alter
>> an adjacent scalar and then restore it (that is, it cannot interfere
>> with scalars in use by another thread) may no longer apply. The program
>> may no longer be thread safe.
> That might also be implementation-dependent.
I was interested in that more specific and wrote a little test.
This test has a structure with two unaligned uint32_ts where one
of them optionally crosses a cacheline-boundary depending on a
macro. Both values are incremented by two threads and each thread
checks in each iteration if the currently read value is that it
was before. If it isn't there's something gonna happen you suppose.
So here's the code:
#include <iostream>
#include <cstddef>
#include <cstdint>
#include <thread>
#include <atomic>
using namespace std;
#define TEST_CACHELINE_BOUNDARIES
size_t const CACHELINE_SIZE = 64;
#pragma pack(1)
struct alignas(CACHELINE_SIZE) UnalignedStruct
{
#ifdef TEST_CACHELINE_BOUNDARIES
char fill[CACHELINE_SIZE - sizeof(uint32_t) - 1];
#else
char fill[1];
#endif
uint32_t volatile a;
uint32_t volatile b;
};
void IncThread( uint32_t volatile *u, atomic_uint *fail_counter )
{
unsigned before;
unsigned c;
for( before = *u, c = 1'000'000'000; c; --c )
{
if( *u != before )
++*fail_counter,
before = *u;
*u = ++before;
}
}
void f( int a, int b, int c )
{
}
int main()
{
UnalignedStruct us;
atomic_uint fail_counter = 0;
thread t1( IncThread, &us.a, &fail_counter ),
t2( IncThread, &us.b, &fail_counter );
t1.join();
t2.join();
cout << (unsigned)fail_counter << " collisions" << endl;
}
So on my Ryzen 7 1800X, I get 0 collisions on one billion iterations.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-08-12 13:06 +0100 |
| Message-ID | <20190812130657.8771056b7d665bf42a5dc212@cvine--nospam--.freeserve.co.uk> |
| In reply to | #67591 |
On Mon, 12 Aug 2019 13:03:36 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
> >> Even with compiler systems that do support accessing words at odd
> >> addresses, there is a potential problem in a multi-threaded program.
> >> The guarantee that, in updating one scalar, the computer cannot alter
> >> an adjacent scalar and then restore it (that is, it cannot interfere
> >> with scalars in use by another thread) may no longer apply. The program
> >> may no longer be thread safe.
>
> > That might also be implementation-dependent.
>
> I was interested in that more specific and wrote a little test.
> This test has a structure with two unaligned uint32_ts where one
> of them optionally crosses a cacheline-boundary depending on a
> macro. Both values are incremented by two threads and each thread
> checks in each iteration if the currently read value is that it
> was before. If it isn't there's something gonna happen you suppose.
> So here's the code:
>
> #include <iostream>
> #include <cstddef>
> #include <cstdint>
> #include <thread>
> #include <atomic>
>
> using namespace std;
>
> #define TEST_CACHELINE_BOUNDARIES
>
> size_t const CACHELINE_SIZE = 64;
>
> #pragma pack(1)
> struct alignas(CACHELINE_SIZE) UnalignedStruct
> {
> #ifdef TEST_CACHELINE_BOUNDARIES
> char fill[CACHELINE_SIZE - sizeof(uint32_t) - 1];
> #else
> char fill[1];
> #endif
> uint32_t volatile a;
> uint32_t volatile b;
> };
>
> void IncThread( uint32_t volatile *u, atomic_uint *fail_counter )
> {
> unsigned before;
> unsigned c;
>
> for( before = *u, c = 1'000'000'000; c; --c )
> {
> if( *u != before )
> ++*fail_counter,
> before = *u;
> *u = ++before;
> }
> }
>
> void f( int a, int b, int c )
> {
> }
>
> int main()
> {
> UnalignedStruct us;
> atomic_uint fail_counter = 0;
> thread t1( IncThread, &us.a, &fail_counter ),
> t2( IncThread, &us.b, &fail_counter );
>
> t1.join();
> t2.join();
> cout << (unsigned)fail_counter << " collisions" << endl;
>
> }
>
> So on my Ryzen 7 1800X, I get 0 collisions on one billion iterations.
I think your Ryzen should be OK for ordinary memory as it supports
the MOESI protocol (which enforces cache line ownership), but I am not
an expert on that. In any event, it is hardware/implementation
dependent.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-12 10:34 +0100 |
| Message-ID | <koa4F.902271$2U7.467289@fx02.am4> |
| In reply to | #67584 |
On 12/08/2019 01:07, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> Actually, most of the time when pack(1) is used, elements will be
>> properly aligned anyway. Because they will be sized and arranged
>> manually to get the most efficient packing.
>>
>> When done properly, then I should be able to comment out the pack(1),
>> and it ought to still work, and with the same sizes of structs, and the
>> same member offsets.
>
> Then there's no point in using pack(1), is there?
It isn't always equivalent. I also like to be aware of the layout of my
structs. I just don't like padding and prefer to make use of that space;
pack(1) provides an incentive to do that to avoid misalignment.
But I asked
> specifically about a case where it causes a member to be aligned
> differently than it would without the pack(1).
The example that you snipped showed how that could result in faster
performance, likely due to the significantly reduced memory
requirements, when the hardware complies.
>> But pack(1) can also be used to define a particular layout, in instances
>> where I don't need to access individual misaligned members, just to get
>> the right overall size.
>
> If you have
> struct foo { char c; int i; }
> (assume int is 4 bytes), and #pragma pack(1) gives the struct a size of
> 5 bytes, then an array of struct foo will result in misaligned members.
Doesn't matter, as the i member is misaligned anyway. (Actually, around
every 4th array element, i will be aligned properly.)
>> (My own compilers target x64.
> [snip]
>
> And since x64 can access words at odd addresses, there's no problem.
It's something you want to keep in mind. As I said, usually you will
strive to keep elements aligned. And the x64 does need alignment in some
areas (the stack must be 64-bit aligned; the ABI requires it to be
128-bit aligned at call-points; and some instructions require strictly
128-bit aligned data).
> If you wanted to target your compiler to systems that don't support
> accessing words at odd addresses, you might have a problem.
Then I'll cross that bridge at the right time. Since at the moment, the
very common x64 and ARM64 architectures appear to allow misaligned
accesses for most data, then that's not something I'm likely to have to
worry about in my lifetime.
(I also concentrate on 64-bit targets. With mixed 32- or 64-bit, then
pack(1) introduces some problems, as sometimes T* is 32 bits, and
sometimes 64, screwing up your carefully crafted layout.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-12 08:49 -0700 |
| Message-ID | <ln5zn275aa.fsf@kst-u.example.com> |
| In reply to | #67590 |
Bart <bc@freeuk.com> writes:
> On 12/08/2019 01:07, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> Actually, most of the time when pack(1) is used, elements will be
>>> properly aligned anyway. Because they will be sized and arranged
>>> manually to get the most efficient packing.
>>>
>>> When done properly, then I should be able to comment out the pack(1),
>>> and it ought to still work, and with the same sizes of structs, and the
>>> same member offsets.
>>
>> Then there's no point in using pack(1), is there?
>
> It isn't always equivalent. I also like to be aware of the layout of my
> structs. I just don't like padding and prefer to make use of that space;
> pack(1) provides an incentive to do that to avoid misalignment.
Do you have a case where pack(1) makes a difference but *doesn't* create
the possibility of unaligned members? Normally compilers insert the
miminal padding necessary to satsify alignment requirement (though this
isn't required).
> But I asked
>> specifically about a case where it causes a member to be aligned
>> differently than it would without the pack(1).
>
> The example that you snipped showed how that could result in faster
> performance, likely due to the significantly reduced memory
> requirements, when the hardware complies.
>
>
>>> But pack(1) can also be used to define a particular layout, in instances
>>> where I don't need to access individual misaligned members, just to get
>>> the right overall size.
>>
>> If you have
>> struct foo { char c; int i; }
>> (assume int is 4 bytes), and #pragma pack(1) gives the struct a size of
>> 5 bytes, then an array of struct foo will result in misaligned members.
>
> Doesn't matter, as the i member is misaligned anyway. (Actually, around
> every 4th array element, i will be aligned properly.)
Sorry, my mistake. I meant that if you have
struct foo { int i; char c; }
then an array of struct foo will result in misaligned members, even
though there likely won't be for a single object.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-12 18:10 +0200 |
| Message-ID | <qis31t$usb$1@news.albasani.net> |
| In reply to | #67599 |
> Sorry, my mistake. I meant that if you have
> struct foo { int i; char c; }
> then an array of struct foo will result in misaligned members,
> even though there likely won't be for a single object.
No, the structure-size is rounded up for that.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-08-12 09:22 -0700 |
| Message-ID | <7ba21901-827f-4116-93a1-ae698e4c3208@googlegroups.com> |
| In reply to | #67600 |
On Monday, 12 August 2019 19:10:46 UTC+3, Bonita Montero wrote:
> > Sorry, my mistake. I meant that if you have
> > struct foo { int i; char c; }
> > then an array of struct foo will result in misaligned members,
> > even though there likely won't be for a single object.
>
> No, the structure-size is rounded up for that.
Not when #pragma pack(1) is used like they discussed. It will
erase such padding.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-12 18:24 +0200 |
| Message-ID | <qis3re$s4g$1@news.albasani.net> |
| In reply to | #67601 |
Am 12.08.2019 um 18:22 schrieb Öö Tiib:
>>> Sorry, my mistake. I meant that if you have
>>> struct foo { int i; char c; }
>>> then an array of struct foo will result in misaligned members,
>>> even though there likely won't be for a single object.
>> No, the structure-size is rounded up for that.
> Not when #pragma pack(1) is used like they discussed. ...
There wasn't any #pragma pack in the former example.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-08-12 16:38 -0700 |
| Message-ID | <a6b2f28d-0021-4e20-b872-5b678dc7ce56@googlegroups.com> |
| In reply to | #67602 |
On Monday, August 12, 2019 at 12:24:24 PM UTC-4, Bonita Montero wrote:
> Am 12.08.2019 um 18:22 schrieb Öö Tiib:
> >>> Sorry, my mistake. I meant that if you have
> >>> struct foo { int i; char c; }
> >>> then an array of struct foo will result in misaligned members,
> >>> even though there likely won't be for a single object.
>
> >> No, the structure-size is rounded up for that.
>
> > Not when #pragma pack(1) is used like they discussed. ...
>
> There wasn't any #pragma pack in the former example.
Please don't interrupt a conversation if you're not willing to pay
sufficient attention to avoid making remarks that betray your lack of
attention. Keith's message dated Sun, 11 Aug 2019 17:07:21 -0700
included a #pragma pack(1) directive, and all of the subsequent
discussion has been about the significance of such a directive. Bart
snipped that line in his response, but his message and Keith's response
both refer to pack(1) as a shorthand for #pragma pack(1). If you didn't
know what "pack(1)" was referring to, you should have asked.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-12 09:33 -0700 |
| Message-ID | <ln1rxq737s.fsf@kst-u.example.com> |
| In reply to | #67601 |
Öö Tiib <ootiib@hot.ee> writes:
> On Monday, 12 August 2019 19:10:46 UTC+3, Bonita Montero wrote:
>> [re-added] Keith Thompson wrote:
>> > Sorry, my mistake. I meant that if you have
>> > struct foo { int i; char c; }
>> > then an array of struct foo will result in misaligned members,
>> > even though there likely won't be for a single object.
>>
>> No, the structure-size is rounded up for that.
>
> Not when #pragma pack(1) is used like they discussed. It will
> erase such padding.
And the quoted (but not attributed) text was a correction to an earlier
statement of mine. In context, the presence of #pragma pack(1) was
clear.
(I won't respond directly to Bonita as long as she inists on deleting
attribution lines.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-11 13:11 -0700 |
| Message-ID | <lnef1r798x.fsf@kst-u.example.com> |
| In reply to | #67557 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> With that alignment decision made, the C standard explicitly says that
> conversions to pointers that result in them being unaligned, are
> undefined behaviour - as is dereferencing unaligned pointers. A C
> implementation can, of course, give a definition for how it treats
> unaligned pointers - but if it does not, then you have to assume that
> they are simply not allowed.
(Did you mean to say "C++ standard"?)
You weaken your argument by using phrases like "not allowed".
There are very few things that are not allowed by the standard.
For undefined behavior, the compiler is not obligated to diagnose
the problem, and the run-time behavior *can* be exactly what someone
might naively expect.
I suggest sticking to the terms defined by the standard itself.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-11 23:59 +0200 |
| Message-ID | <qiq33e$on6$1@dont-email.me> |
| In reply to | #67570 |
On 11/08/2019 22:11, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> With that alignment decision made, the C standard explicitly says that >> conversions to pointers that result in them being unaligned, are >> undefined behaviour - as is dereferencing unaligned pointers. A C >> implementation can, of course, give a definition for how it treats >> unaligned pointers - but if it does not, then you have to assume that >> they are simply not allowed. > > (Did you mean to say "C++ standard"?) I had been quoting from the C standards, because I am more familiar with them. James showed similar quotations from the C++ standards. > > You weaken your argument by using phrases like "not allowed". > There are very few things that are not allowed by the standard. > For undefined behavior, the compiler is not obligated to diagnose > the problem, and the run-time behavior *can* be exactly what someone > might naively expect. > > I suggest sticking to the terms defined by the standard itself. > Fair enough. I have been a little too colloquial in my language. Yes, I did mean "undefined behaviour". And that means the standards say nothing about the results - there are no guarantees of getting the effects you want (unless the compiler documentation gives additional information), but equally nothing to say that you /won't/ get the results you want.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-08-10 19:31 -0400 |
| Message-ID | <qink4j$nn2$1@dont-email.me> |
| In reply to | #67537 |
On 8/10/19 5:46 PM, David Brown wrote: > On 10/08/2019 17:21, Bonita Montero wrote: >>> More importantly here, it also does not mean you can take pointers >>> to the unaligned members and use them as normal pointers, ... >> >> Quote the part of the standard that says that. > > I already did. > > These are from N1570, draft of C11 standard - C++ inherits this from C > and the C standards are simpler. Actually, no. C++ cross-references the C standard for many purposes. For instance, it has no description of it's own for virtually the entire C standard library, incorporating it into the C++ standard library almost entirely by reference. However, most features in C++ are explicitly stated in the C++ standard, even when their content is exactly the same as clauses in the C standard. Here's what the C++ standard says about alignment: "Object types have alignment requirements (6.9.1, 6.9.2) which place restrictions on the addresses at which an object of that type may be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated. An object type imposes an alignment requirement on every object of that type; stricter alignment can be requested using the alignment specifier (10.6.2)." (6.11p1) Pointer conversions are covered by "If the original pointer value represents the address A of a byte in memory and A does not satisfy the alignment requirement of T, then the resulting pointer value is unspecified." (8.2.9p13) While 8.2.9p13 is specifically about static_cast<>, no other way of converting pointers even addresses performing such pointer conversions, except insofar as the behavior of reinterpret_cast<> is defined in terms of corresponding static_cast<> conversions (8.2.10p7). Trying to use any other method of performing such a conversion has undefined behavior because the "Standard omits any explicit definition of the behavior..." (3.27).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-11 15:52 +0200 |
| Message-ID | <qip6it$of5$1@dont-email.me> |
| In reply to | #67542 |
On 11/08/2019 01:31, James Kuyper wrote: > On 8/10/19 5:46 PM, David Brown wrote: >> On 10/08/2019 17:21, Bonita Montero wrote: >>>> More importantly here, it also does not mean you can take pointers >>>> to the unaligned members and use them as normal pointers, ... >>> >>> Quote the part of the standard that says that. >> >> I already did. >> >> These are from N1570, draft of C11 standard - C++ inherits this from C >> and the C standards are simpler. > > Actually, no. C++ cross-references the C standard for many purposes. For > instance, it has no description of it's own for virtually the entire C > standard library, incorporating it into the C++ standard library almost > entirely by reference. However, most features in C++ are explicitly > stated in the C++ standard, even when their content is exactly the same > as clauses in the C standard. Here's what the C++ standard says about > alignment: > > "Object types have alignment requirements (6.9.1, 6.9.2) which place > restrictions on the addresses at which an object of that type may be > allocated. An alignment is an implementation-defined integer value > representing the number of bytes between successive addresses at which a > given object can be allocated. An object type imposes an alignment > requirement on every object of that type; stricter alignment can be > requested using the alignment specifier (10.6.2)." (6.11p1) > > Pointer conversions are covered by > "If the original pointer value represents the address A of a byte in > memory and A does not satisfy the alignment requirement of T, then the > resulting pointer value is unspecified." (8.2.9p13) > > While 8.2.9p13 is specifically about static_cast<>, no other way of > converting pointers even addresses performing such pointer conversions, > except insofar as the behavior of reinterpret_cast<> is defined in terms > of corresponding static_cast<> conversions (8.2.10p7). Trying to use any > other method of performing such a conversion has undefined behavior > because the "Standard omits any explicit definition of the behavior..." > (3.27). > Thank you for being more accurate here. I am not as familiar with the C++ standards as with the C standards - there are new C++ versions published faster than I get up to speed with them.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-11 07:28 +0200 |
| Message-ID | <qio92h$279$5@news.albasani.net> |
| In reply to | #67537 |
>>> More importantly here, it also does not mean you can take pointers >>> to the unaligned members and use them as normal pointers, ... >> Quote the part of the standard that says that. > I already did. I corrected my posting: I said that not the standard is relevant here but the compiler-documentation since we're talking about a compiler -specific featre.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-08-10 16:37 -0700 |
| Message-ID | <9625beba-bea3-4ed8-8819-3d76f6b5836b@googlegroups.com> |
| In reply to | #67527 |
On Saturday, August 10, 2019 at 11:21:30 AM UTC-4, Bonita Montero wrote: > > More importantly here, it also does not mean you can take pointers > > to the unaligned members and use them as normal pointers, ... > > Quote the part of the standard that says that. You mean you've been saying all this without knowing what the relevant texts say? I've been assuming all along that you were asserting that what the standard says doesn't matter - that what actual implementations do is the only thing that matters, and that you were simply unaware of the real-world implementations where such code doesn't work. That you were actually ignorant of clauses 6.11p1 and 8.29p13 of the C++ standard (the relevant details are cited in a recent response of mine to David's response) hadn't occurred to me.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-09 21:35 +0200 |
| Message-ID | <qikhtr$m5q$1@news.albasani.net> |
| In reply to | #67487 |
And the gcc-documentation says to its #pragma pack directive: "For compatibility with Microsoft Windows compilers, GCC supports a set of #pragma directives that change the maximum alignment of members of structures (other than zero-width bit-fields), unions, and classes subsequently defined. The n value below always is required to be a small power of two and specifies the new alignment in bytes." I think the guarantees gcc makes here are only for the gererated code and not, that the code might really run on all platforms because some of the target-platforms might not emulate unaligned operations through trapping. But on target-platforms where the CPU allows unaligned oper- ations this a clear guarantee that it will work.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 21:43 +0200 |
| Message-ID | <qihu0u$1bv$1@dont-email.me> |
| In reply to | #67454 |
On 08/08/2019 17:35, Bonita Montero wrote: >> Show me links to the documentation supporting this claim. > > There needs not to be any documentation on that. The thing is simply > that the compiler usually won't see that an access is unaligned in mot > times so it can't be incompatible to this. So the whole thing is simply > defined by the architecture and not by the compiler. > So it is all speculation and guesswork, with no evidence, documentation or recommendations to back up your position. And as compilers get better, and in particular as link-time optimisation (or "omniscient compilation") becomes more popular so that compilers /can/ see when accesses are aligned or not, the risk of things breaking gets higher.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-08-08 12:51 +0000 |
| Message-ID | <slrnqko6mh.cdo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #67383 |
On Wed, 2019-08-07, Bonita Montero wrote: [David Brown, attribution missing as usual] >> Can you give any kind of a reference for even a single case where you >> know the OS will trap unaligned accesses and emulate them in software? > > It's just a tiny task to support this by an OS and helps to run a lot > of old code; so this is very likely. I take that as a 'no'. (That aspect got lost in David Brown's frustrated response, which is the only reason I bring it up.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web