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 | 15 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 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 15:53 +0200 |
| Message-ID | <qih9ft$9v1$1@dont-email.me> |
| In reply to | #67439 |
On 08/08/2019 14:48, Bart wrote:
> On 08/08/2019 09:39, David Brown wrote:
>> On 07/08/2019 23:52, Bart wrote:
>
>> I don't see much connection between struct sizes and what we have
>> discussing, but I will try to answer anyway.
>
> I was picking up on the suggestion to just let a compiler get on with
> its job. I'm saying that for things like this it will still need to be
> checked, and if necessary to tweak a struct to get a more satisfactory
> result.
>
Struct size and padding follows strict rules - it is not something that
varies between compilers (for the same target ABI), by versions or by
options. If you know the rules, the results are always predictable.
(Of course they can still be hard to check manually if the struct is big
or the member types are complicated).
Occasionally you will want to tweak a struct for better results. For
example, if it is of size 60 bytes, you might want to add a 4-byte dummy
entry so that it is 64 bytes giving more efficient use in an array
(especially when you arrange for it to have the same alignment as a
cache line). But that sort of thing is not very common.
> That can include deliberately using some misalignment although usually
> you will try and avoid that.
I don't imagine there is much use for deliberate misalignment. But
sometimes additional alignment (typically to cache line size) can be
helpful.
>
>> Compilers will add padding in structs to keep alignments correct for the
>> fields. The alignment for the struct itself will be that of the largest
>> alignment of any field, and there will be padding at the end of the
>> struct if needed to make the whole thing a multiple of this alignment
>> (so that arrays of the struct work).
>>
>> So you won't get a struct array that has a stride of 65 bytes unless the
>> struct itself has size 65 bytes.
>
> The size might be 65 or more than 65, neither ideal if you were hoping
> for 64.
True. But the size and padding follows set rules, which allows you to
re-arrange fields to minimise padding.
>
> (If I'm generating C, then I'd use pack(1) since the source language
> does not do automatic padding, and then a size of 65 is possible for any
> mix of element types. Although that would usually be picked up in the
> original language before I start generating C versions.)
I think if you want to translate directly from your source language into
C concepts, you should make your source language match the C rules here.
>
>> As for checking the size of structs, compilers might be able to give you
>> help such as gcc's "-Wpadded" warning that is issued if there is any
>> padding added to structs. Most people don't want such a warning, of
>> course, but I have sometimes found it useful.
>>
>> The best method of checking struct sizes IMHO is with C11 static
>> assertions:
>>
>> _Static_assert(sizeof(struct X) == 65, "Struct X should be 65 bytes");
>
> I would just use printf("size = %<whatever>\n",sizeof(struct X)) while
> creating it. Just to ensure it is some sane value.
>
IMHO, it is a lot better to have a compile-time assertion that is always
checked whenever the code is compiled, than a run-time check that you
confirm manually when you remember to include it and when you remember
to look at it. Printing the size of the struct can be handy if the
static assertion fails and you can't immediately see why - the static
assertion will tell you the struct is not 65 bytes, but it won't tell
you what it actually is.
>> But there are several ways
>> to avoid that in gcc:
>>
>> 1. Enable optimisation. That will coalesce the byte-at-a-time accesses
>> on targets that support unaligned accesses.
>
> On that specific example (that would have been on gcc 4.x on RPi in
> 2012), it was optimised, and the ARM32 processor /was/ capable of
> unaligned access, but gcc still generated byte-at-a-time code).
>
It's hard to guess details from that description. But it is fair to say
the "enable optimisation" has no guarantees - gcc can spot common
patterns and optimise them, but not all possible patterns. And results
can vary by compiler version and target, with improvements for each
generation. "gcc 4.x" could be nearly 15 years old, or just 5 years old.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-07 17:27 -0700 |
| Message-ID | <lnd0hga4da.fsf@kst-u.example.com> |
| In reply to | #67401 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Compiler extensions like "packed" are fine in my book. Use them if they
> make the code clearer and more efficient - assuming, of course, that the
> lack of portability is not a problem. Compilers that don't support such
> features will complain, so you don't get silent problems.
Compiler extension like "packed" can cause problems. For example,
suppose you have something like this (using gcc syntax):
struct foo {
char c;
int i;
} __attribute__((packed));
foo obj;
some_func(&obj.i);
some_func() takes an argument of type int*, but there's no indication
that it's misaligned, so it can't take any special steps to avoid
blowing up when it dereferences its argument.
Recent versions of gcc and clang warn about taking the address of a
misaligned member of a packed structure.
https://stackoverflow.com/q/8568432/827263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--
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-08 10:43 +0200 |
| Message-ID | <qignba$d1a$1@dont-email.me> |
| In reply to | #67412 |
On 08/08/2019 02:27, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Compiler extensions like "packed" are fine in my book. Use them if they
>> make the code clearer and more efficient - assuming, of course, that the
>> lack of portability is not a problem. Compilers that don't support such
>> features will complain, so you don't get silent problems.
>
> Compiler extension like "packed" can cause problems. For example,
> suppose you have something like this (using gcc syntax):
>
> struct foo {
> char c;
> int i;
> } __attribute__((packed));
> foo obj;
> some_func(&obj.i);
>
> some_func() takes an argument of type int*, but there's no indication
> that it's misaligned, so it can't take any special steps to avoid
> blowing up when it dereferences its argument.
>
> Recent versions of gcc and clang warn about taking the address of a
> misaligned member of a packed structure.
>
> https://stackoverflow.com/q/8568432/827263
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
Agreed.
I did not mean to imply that "packed" is something you should use widely
- IMHO, it is usually a poor choice, and I rarely use it myself. I
merely mean that I think it is fine to use compiler-specific features
like that if they give you the code you need. They are defined
behaviour for the compiler you are using, and give hard compile-time
errors on compilers that don't support them. The code will not be as
portable, but you will avoid surprises with silent errors.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-08 13:33 -0700 |
| Message-ID | <lntvar8kje.fsf@kst-u.example.com> |
| In reply to | #67433 |
David Brown <david.brown@hesbynett.no> writes:
> On 08/08/2019 02:27, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> Compiler extensions like "packed" are fine in my book. Use them if they
>>> make the code clearer and more efficient - assuming, of course, that the
>>> lack of portability is not a problem. Compilers that don't support such
>>> features will complain, so you don't get silent problems.
>>
>> Compiler extension like "packed" can cause problems. For example,
>> suppose you have something like this (using gcc syntax):
>>
>> struct foo {
>> char c;
>> int i;
>> } __attribute__((packed));
>> foo obj;
>> some_func(&obj.i);
>>
>> some_func() takes an argument of type int*, but there's no indication
>> that it's misaligned, so it can't take any special steps to avoid
>> blowing up when it dereferences its argument.
>>
>> Recent versions of gcc and clang warn about taking the address of a
>> misaligned member of a packed structure.
>>
>> https://stackoverflow.com/q/8568432/827263
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>>
>
> Agreed.
>
> I did not mean to imply that "packed" is something you should use widely
> - IMHO, it is usually a poor choice, and I rarely use it myself. I
> merely mean that I think it is fine to use compiler-specific features
> like that if they give you the code you need. They are defined
> behaviour for the compiler you are using, and give hard compile-time
> errors on compilers that don't support them. The code will not be as
> portable, but you will avoid surprises with silent errors.
The bug report I cited shows a case where "packed" gives *undefined*
behavior by generating an invalid pointer without using pointer casts.
--
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-08 23:34 +0200 |
| Message-ID | <qii4gb$5o8$1@dont-email.me> |
| In reply to | #67465 |
On 08/08/2019 22:33, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 08/08/2019 02:27, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> Compiler extensions like "packed" are fine in my book. Use them if they
>>>> make the code clearer and more efficient - assuming, of course, that the
>>>> lack of portability is not a problem. Compilers that don't support such
>>>> features will complain, so you don't get silent problems.
>>>
>>> Compiler extension like "packed" can cause problems. For example,
>>> suppose you have something like this (using gcc syntax):
>>>
>>> struct foo {
>>> char c;
>>> int i;
>>> } __attribute__((packed));
>>> foo obj;
>>> some_func(&obj.i);
>>>
>>> some_func() takes an argument of type int*, but there's no indication
>>> that it's misaligned, so it can't take any special steps to avoid
>>> blowing up when it dereferences its argument.
>>>
>>> Recent versions of gcc and clang warn about taking the address of a
>>> misaligned member of a packed structure.
>>>
>>> https://stackoverflow.com/q/8568432/827263
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>>>
>>
>> Agreed.
>>
>> I did not mean to imply that "packed" is something you should use widely
>> - IMHO, it is usually a poor choice, and I rarely use it myself. I
>> merely mean that I think it is fine to use compiler-specific features
>> like that if they give you the code you need. They are defined
>> behaviour for the compiler you are using, and give hard compile-time
>> errors on compilers that don't support them. The code will not be as
>> portable, but you will avoid surprises with silent errors.
>
> The bug report I cited shows a case where "packed" gives *undefined*
> behavior by generating an invalid pointer without using pointer casts.
>
I think you are asking for trouble by taking a pointer to a misaligned
member of a packed struct. But it would better if the compiler told you
this was a problem. I'd have preferred it to be an error (like taking
the address of a member of a struct with the "scalar_storage_order"
attribute for changing endianness), but a warning is OK. It took a long
time to get this fixed, however - 7 years!
[toc] | [prev] | [next] | [standalone]
| From | Christopher Collins <ccollins476ad@gmail.com> |
|---|---|
| Date | 2019-08-07 17:28 -0700 |
| Message-ID | <slrnqkmr4h.1th.ccollins476ad@pseudoephedrine.nightmare-heaven.no-ip.biz> |
| In reply to | #67401 |
On 2019-08-07, David Brown <david.brown@hesbynett.no> wrote:
> On 07/08/2019 21:50, Christopher Collins wrote:
>> On 2019-08-07, David Brown <david.brown@hesbynett.no> wrote:
>>> There is rarely any reason for wanting unaligned access, and no
>>> justification for using it in code that should be portable.
>>
>> There is one good reason for wanting it: reduced code size.
>
> Nope.
>
> Write your code properly and safely (using shifts and masks, memcpy, or
> compiler-specific features or intrinsics) and let the compiler turn it
> into unaligned accesses. Writing safe, correct, and valid source code
> is the programmer's responsibility. Turning it into small and fast
> object code is the compiler's responsibility. Don't try to do the
> compiler's job - work with it so that it can to the best job it can.
I did an experiment using godbolt (ARM gcc 8.2, compiler settings:
-mcpu=cortex-m4 -Os). In the below code, there are two functions,
`marshal1` and `marshal2`. Both functions serialize an object of type
`struct msg` into a byte array. `marshal1` does it member-by-member;
`marshal2` does it with a single memcpy as I described in my previous
post.
// Code:
#include <inttypes.h>
#include <string.h>
struct msg {
uint8_t a;
uint32_t b;
uint16_t c;
uint8_t d;
uint16_t e[4];
} __attribute__((packed));
void marshal1(const struct msg *m, uint8_t *out) {
out[0] = m->a;
memcpy(&out[1], &m->b, 4);
memcpy(&out[5], &m->c, 2);
out[7] = m->d;
memcpy(&out[8], m->e, 8);
}
void marshal2(const struct msg *m, uint8_t *out) {
memcpy(out, m, sizeof *m);
}
// Result:
marshal1:
ldrb r3, [r0] @ zero_extendqisi2
strb r3, [r1]
ldr r3, [r0, #1] @ unaligned
str r3, [r1, #1] @ unaligned
ldrh r3, [r0, #5] @ unaligned
strh r3, [r1, #5] @ unaligned
ldrb r3, [r0, #7] @ zero_extendqisi2
strb r3, [r1, #7]
ldr r3, [r0, #8]! @ unaligned
str r3, [r1, #8] @ unaligned
ldr r3, [r0, #4] @ unaligned
str r3, [r1, #12] @ unaligned
bx lr
marshal2:
add r3, r0, #16
.L3:
ldr r2, [r0], #4 @ unaligned
str r2, [r1], #4 @ unaligned
cmp r0, r3
bne .L3
bx lr
The output for `marshal2` is obviously smaller than `marshal1`. How can
I acheive the same results without relying on this technique?
Chris
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 09:30 +0200 |
| Message-ID | <qigj1o$rh8$1@news.albasani.net> |
| In reply to | #67414 |
Am 08.08.2019 um 02:28 schrieb Christopher Collins:
> On 2019-08-07, David Brown <david.brown@hesbynett.no> wrote:
>> On 07/08/2019 21:50, Christopher Collins wrote:
>>> On 2019-08-07, David Brown <david.brown@hesbynett.no> wrote:
>>>> There is rarely any reason for wanting unaligned access, and no
>>>> justification for using it in code that should be portable.
>>>
>>> There is one good reason for wanting it: reduced code size.
>>
>> Nope.
>>
>> Write your code properly and safely (using shifts and masks, memcpy, or
>> compiler-specific features or intrinsics) and let the compiler turn it
>> into unaligned accesses. Writing safe, correct, and valid source code
>> is the programmer's responsibility. Turning it into small and fast
>> object code is the compiler's responsibility. Don't try to do the
>> compiler's job - work with it so that it can to the best job it can.
>
> I did an experiment using godbolt (ARM gcc 8.2, compiler settings:
> -mcpu=cortex-m4 -Os). In the below code, there are two functions,
> `marshal1` and `marshal2`. Both functions serialize an object of type
> `struct msg` into a byte array. `marshal1` does it member-by-member;
> `marshal2` does it with a single memcpy as I described in my previous
> post.
>
> // Code:
>
> #include <inttypes.h>
> #include <string.h>
>
> struct msg {
> uint8_t a;
> uint32_t b;
> uint16_t c;
> uint8_t d;
> uint16_t e[4];
> } __attribute__((packed));
>
> void marshal1(const struct msg *m, uint8_t *out) {
> out[0] = m->a;
> memcpy(&out[1], &m->b, 4);
> memcpy(&out[5], &m->c, 2);
> out[7] = m->d;
> memcpy(&out[8], m->e, 8);
> }
>
> void marshal2(const struct msg *m, uint8_t *out) {
> memcpy(out, m, sizeof *m);
> }
>
> // Result:
>
> marshal1:
> ldrb r3, [r0] @ zero_extendqisi2
> strb r3, [r1]
> ldr r3, [r0, #1] @ unaligned
> str r3, [r1, #1] @ unaligned
> ldrh r3, [r0, #5] @ unaligned
> strh r3, [r1, #5] @ unaligned
> ldrb r3, [r0, #7] @ zero_extendqisi2
> strb r3, [r1, #7]
> ldr r3, [r0, #8]! @ unaligned
> str r3, [r1, #8] @ unaligned
> ldr r3, [r0, #4] @ unaligned
> str r3, [r1, #12] @ unaligned
> bx lr
> marshal2:
> add r3, r0, #16
> .L3:
> ldr r2, [r0], #4 @ unaligned
> str r2, [r1], #4 @ unaligned
> cmp r0, r3
> bne .L3
> bx lr
>
> The output for `marshal2` is obviously smaller than `marshal1`. How can
> I acheive the same results without relying on this technique?
>
> Chris
What you do doesn't makes sense. When you have a packed data-structure
it's those which you want to persist or send over the network. So what
you put to out should be directly what the data-structure holds.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 14:20 -0700 |
| Message-ID | <qiffbk$1cjj$1@gioia.aioe.org> |
| In reply to | #67377 |
On 8/7/2019 8:30 AM, David Brown wrote: > /Please/ learn to use Usenet properly! Keep attributions, and quote an > appropriate amount of context! > > On 07/08/2019 16:53, Bonita Montero wrote: >> For portability-reasons almost any system tries to be comatible to >> x86-systems for unaligned accesses. > > Total nonsense. > > There is rarely any reason for wanting unaligned access, and no > justification for using it in code that should be portable. Abusing the bus lock on Intel via forced unaligned cache line straddling hack can be useful in rare algorithms. [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-07 17:27 -0700 |
| Message-ID | <lnblx0a4ce.fsf@kst-u.example.com> |
| In reply to | #67377 |
David Brown <david.brown@hesbynett.no> writes:
> /Please/ learn to use Usenet properly! Keep attributions, and quote an
> appropriate amount of context!
>
> On 07/08/2019 16:53, Bonita Montero wrote:
[SNIP]
It's not a matter of learning. Bonita Montero's headers indicate
that she(?) is using Thunderbird, which I'm reasonably sure handles
attribution lines correctly. She must be removing them deliberately.
I asked her to keep attribution lines a while ago. She responded
with insults.
Do you use a killfile?
--
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-08 11:39 +0200 |
| Message-ID | <qigqlc$sk2$1@dont-email.me> |
| In reply to | #67413 |
On 08/08/2019 02:27, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> /Please/ learn to use Usenet properly! Keep attributions, and quote an >> appropriate amount of context! >> >> On 07/08/2019 16:53, Bonita Montero wrote: > [SNIP] > > It's not a matter of learning. Bonita Montero's headers indicate > that she(?) is using Thunderbird, which I'm reasonably sure handles > attribution lines correctly. She must be removing them deliberately. > I asked her to keep attribution lines a while ago. She responded > with insults. > > Do you use a killfile? > I do have a killfile (or, to be precise, Thunderbird filter rules), but don't put people in it very often - mostly it is for spambots. Usually I just ignore most of their posts - as I have done with Bonita's in the past, and probably will in the future. Sometimes I find a topic interesting enough or important enough to override my "manual killfile". I don't think there is any one good solution to all this - there is no way to have a free and open Usenet and yet force people to follow simple rules and common courtesy, and no way to block all rudeness without also blocking things of interest. We just all have to make a balance that seems good enough for ourselves.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-08-07 19:48 +0000 |
| Message-ID | <slrnqkmanm.cdo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #67369 |
On Wed, 2019-08-07, David Brown wrote: > On 07/08/2019 14:47, Bonita Montero wrote: >>> What's the point of the exercise, in a C++ context? Unaligned access >>> in portable code is always the result of a programming error. >> >> Pure theory. All platforms support unaligned access either directly >> through the CPU or through trapping by the operating-system (very slow). > > No, they don't. Some cpus support direct unaligned accesses. For > others, various things could happen. On big OS's, you are likely to get > a trap or exception causing the OS to kill your program with a fault - I > can't imagine why an OS would bother simulating the unaligned access. Somewhere in my career I saw some system do that simulation. I can't remember where, but I think we disabled the feature after a while, when we saw it caused a lot more problems than it solved (broken programs would slow down to a crawl instead of crashing and thereby telling us they were broken). I think it was an ARM of some kind. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-07 15:51 -0700 |
| Message-ID | <lnk1boa8ti.fsf@kst-u.example.com> |
| In reply to | #67369 |
David Brown <david.brown@hesbynett.no> writes:
> On 07/08/2019 14:47, Bonita Montero wrote:
>>> What's the point of the exercise, in a C++ context? Unaligned access
>>> in portable code is always the result of a programming error.
>>
>> Pure theory. All platforms support unaligned access either directly
>> through the CPU or through trapping by the operating-system (very slow).
>
> No, they don't. Some cpus support direct unaligned accesses. For
> others, various things could happen. On big OS's, you are likely to get
> a trap or exception causing the OS to kill your program with a fault - I
> can't imagine why an OS would bother simulating the unaligned access.
> On embedded systems, unaligned access may lead to a bus fault of some
> sort, halting the system or causing a restart. And on some systems that
> I have used, unaligned access will silently give you muddled reads and
> corrupting writes.
Agreed.
> Unaligned access is always an error. Use code with shifts and masks, if
> you need it, or use memcpy. If your compiler isn't good enough to give
> you efficient enough code for your needs, get a better compiler.
I suppose that depends on what you mean by "unaligned".
For example, as I understand it x86 and x86_64 support accessing
words at odd addresses in hardware, using the same CPU instructions
as an aligned access but executing more slowly. If you want
to extract a 32-bit value from an odd address, and you know
you're running on an x86 or x86_64 and you're not concerned with
portability, you might as well use a word move instruction in
assembly or a simple assignment in C++. You *could* break it down
into byte moves, but the resulting code would be slower.
For some CPUs, aligned access gives you better performance, but
unaligned access still works. For others, unaligned access just goes
kablooie.
--
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-08 12:51 +0200 |
| Message-ID | <qiguqk$gnr$1@dont-email.me> |
| In reply to | #67411 |
On 08/08/2019 00:51, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 07/08/2019 14:47, Bonita Montero wrote: >>>> What's the point of the exercise, in a C++ context? Unaligned access >>>> in portable code is always the result of a programming error. >>> >>> Pure theory. All platforms support unaligned access either directly >>> through the CPU or through trapping by the operating-system (very slow). >> >> No, they don't. Some cpus support direct unaligned accesses. For >> others, various things could happen. On big OS's, you are likely to get >> a trap or exception causing the OS to kill your program with a fault - I >> can't imagine why an OS would bother simulating the unaligned access. >> On embedded systems, unaligned access may lead to a bus fault of some >> sort, halting the system or causing a restart. And on some systems that >> I have used, unaligned access will silently give you muddled reads and >> corrupting writes. > > Agreed. > >> Unaligned access is always an error. Use code with shifts and masks, if >> you need it, or use memcpy. If your compiler isn't good enough to give >> you efficient enough code for your needs, get a better compiler. > > I suppose that depends on what you mean by "unaligned". > > For example, as I understand it x86 and x86_64 support accessing > words at odd addresses in hardware, using the same CPU instructions > as an aligned access but executing more slowly. If you want > to extract a 32-bit value from an odd address, and you know > you're running on an x86 or x86_64 and you're not concerned with > portability, you might as well use a word move instruction in > assembly or a simple assignment in C++. You *could* break it down > into byte moves, but the resulting code would be slower. > The distinction here must be between what is allowed by the language (combining the standards and any compiler-specific defined features) and what is allowed by the hardware. Many processors support unaligned accesses. For some, these give significant speed penalties or limitations (such as being non-atomic), while others have more efficient support. But C (and C++) does not support unaligned accesses. Most ways of creating pointers to unaligned objects are undefined behaviour even before you try to use them for access. So the correct way to code this is using either portable constructs (such as memcpy) which are given as byte moves, or using some implementation-specific feature. It is then up to the compiler to turn this into optimal code, such as using an unaligned move instruction. It is not necessarily slower - indeed, on gcc you will get a single word move instruction for a variety of different byte move combinations. The nearest standard C has to saying "I want this to be a single word move regardless of alignment" is to use volatile pointers. Compilers rarely document what would happen in this case, but it would be an extremely odd compiler that did not issue the access regardless of alignment, invalid pointer casts, etc. > For some CPUs, aligned access gives you better performance, but > unaligned access still works. For others, unaligned access just goes > kablooie. > Yes, that's a fine way to describe it!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-08 14:46 +0000 |
| Message-ID | <NAW2F.154133$jl6.78130@fx04.iad> |
| In reply to | #67438 |
David Brown <david.brown@hesbynett.no> writes: >On 08/08/2019 00:51, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 07/08/2019 14:47, Bonita Montero wrote: > >But C (and C++) does not support unaligned accesses. Just a nit, but the _standard_ doesn't support unaligned accesses. Every C and C++ compiler I've used supports them (both via some compiler specific 'packed' attribute and via simple casts). And while the behavior is undefined per the standard, it's quite well defined per architecture if not portable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 17:14 +0200 |
| Message-ID | <qihe86$65l$1@dont-email.me> |
| In reply to | #67444 |
On 08/08/2019 16:46, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 08/08/2019 00:51, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 07/08/2019 14:47, Bonita Montero wrote: > >> >> But C (and C++) does not support unaligned accesses. > > Just a nit, but the _standard_ doesn't support unaligned accesses. > Unless you are talking about a specific compiler, the standard /is/ the language. > Every C and C++ compiler I've used supports them (both via some > compiler specific 'packed' attribute and via simple casts). A compiler supports features beyond the standards if it documents that it supports them. Other than that, you are in the realms of "it worked when I tested it" - i.e., luck and a problem waiting to happen. So if your compiler says it works okay, that's fine - for that compiler. If it supports "packed" attributes, or "__unaligned" keywords, use them - that's fine. > > And while the behavior is undefined per the standard, it's quite > well defined per architecture if not portable. > Sure, unaligned access is often defined on the underlying architecture. But unless you are programming in assembly, that doesn't matter.
[toc] | [prev] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.lang.c++
csiph-web