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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 16:55 +0200 |
| Message-ID | <qihd45$lur$1@news.albasani.net> |
| In reply to | #67440 |
>>> 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'. No, that's a "mostly". But it's stupid to rely on that because it's extremely inefficient - an article on the Web I found reported a slow- down of about 300x over manually assembling the data-type like I did it in the code I have shown here on Solaris / SPARC. It's just a fallback for old code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 16:57 +0200 |
| Message-ID | <qihd97$m00$1@news.albasani.net> |
| In reply to | #67448 |
>>>> 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'. > No, that's a "mostly". But it's stupid to rely on that because it's > extremely inefficient - an article on the Web I found reported a slow- > down of about 300x over manually assembling the data-type like I did > it in the code I have shown here on Solaris / SPARC. Sorry, this wasn't correct. The benchmark was a comparison of emulated unaligned accesses through trapping with aligned accesses. But the differrence was about 300x.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 16:07 +0000 |
| Message-ID | <LGC2F.154427$ej3.58524@fx36.iad> |
| 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! Good luck with that, it's been tried before. > >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. > >Other cpu designs do not attempt to copy the x86. Certainly not the instruction set, unless you consider AMD, Cyrix, Nat Semi, Harris, IBM, TI or Transmeta :-) On the other hand, any processor vendor attempting to make a competing server processor will have to accomodate the standard programming methods used on Intel processors if they want to gain any market share since most of the software would be ported from X86. That means things like unaligned accesses and providing something that looks like the intel strongly (program) ordered memory model are high on the desirable feature list. AArch64 was specifically designed to be a competing server processor and thus supports unaligned accesses. The memory model is a bit weaker but generally provides program ordering; a small percentage of software ported from x86 may require some changes (unless it uses the appropriate C11 or C++14 capabilities). > >Many cpus implement unaligned accesses - because the designers think the >balance between use and cost makes it appropriate. It is /not/ for >compatibility with x86. For ARMv8 it was _specifically_ for compatibility with X86(_64).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 18:38 +0200 |
| Message-ID | <qieup8$o2f$1@news.albasani.net> |
| In reply to | #67381 |
> AArch64 was specifically designed to be a competing server processor and thus > supports unaligned accesses. The memory model is a bit weaker but generally > provides program ordering; a small percentage of software ported from x86 > may require some changes (unless it uses the appropriate C11 or C++14 > capabilities). I don't think that ARM is cosiderring AArch64-implementations as a server-competitor. It's just convenient to have unaligned loads / stores for persistence and network-transfers.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 17:34 +0000 |
| Message-ID | <5ZD2F.342001$5i.160868@fx46.iad> |
| In reply to | #67384 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> AArch64 was specifically designed to be a competing server processor and thus >> supports unaligned accesses. The memory model is a bit weaker but generally >> provides program ordering; a small percentage of software ported from x86 >> may require some changes (unless it uses the appropriate C11 or C++14 >> capabilities). > >I don't think that ARM is cosiderring AArch64-implementations as a >server-competitor. It doesn't matter what you think. You can't even be troubled to properly attribute your posts. Aarch64 was specifically designed as a server-capable processor. I was there.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 20:07 +0200 |
| Message-ID | <qif41o$a84$1@news.albasani.net> |
| In reply to | #67387 |
> It doesn't matter what you think. You can't even be troubled to > properly attribute your posts. > Aarch64 was specifically designed as a server-capable processor. > I was there. All attempts to establish Aarch64-based machines as servers failed. F.e. this here: https://en.wikipedia.org/wiki/Calxeda The people simply want x86 and in rare cases SPARC or POWER. And I doubt that Aarch64 was designed mainly with servers in mind. A 64 bit address-space has advantages even on smartphones with <= 4GB RAM.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 20:16 +0000 |
| Message-ID | <WkG2F.264566$GS1.163365@fx48.iad> |
| In reply to | #67388 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> It doesn't matter what you think. You can't even be troubled to >> properly attribute your posts. > >> Aarch64 was specifically designed as a server-capable processor. >> I was there. > >All attempts to establish Aarch64-based machines as servers failed. And again, you are incorrect. https://www.cray.com/blog/inside-isambard-worlds-first-production-arm-supercomputer/ https://www.nextplatform.com/2017/11/13/cray-arms-highest-end-supercomputer-thunderx2/ There are also various cloud deployments. >F.e. this here: https://en.wikipedia.org/wiki/Calxeda Calxeda was using large arrays of A9's (32-bit processors). > >And I doubt that Aarch64 was designed mainly with servers in mind. As I said, I was there.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 22:42 +0200 |
| Message-ID | <qifd3i$gec$1@news.albasani.net> |
| In reply to | #67400 |
>> All attempts to establish Aarch64-based machines as servers failed. > And again, you are incorrect. > https://www.cray.com/blog/inside-isambard-worlds-first-production-arm-supercomputer/ > https://www.nextplatform.com/2017/11/13/cray-arms-highest-end-supercomputer-thunderx2/ We were talking about servers.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 21:19 +0000 |
| Message-ID | <yfH2F.150723$cR3.95879@fx38.iad> |
| In reply to | #67403 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >>> All attempts to establish Aarch64-based machines as servers failed. > >> And again, you are incorrect. >> https://www.cray.com/blog/inside-isambard-worlds-first-production-arm-supercomputer/ > > >https://www.nextplatform.com/2017/11/13/cray-arms-highest-end-supercomputer-thunderx2/ > >We were talking about servers. And if you think a supercomputer isn't a server (or more properly, a collection of servers), you've not been paying attention.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 23:40 +0200 |
| Message-ID | <qifgg8$91u$1@news.albasani.net> |
| In reply to | #67406 |
>>> https://www.cray.com/blog/inside-isambard-worlds-first-production-arm-supercomputer/ >> https://www.nextplatform.com/2017/11/13/cray-arms-highest-end-supercomputer-thunderx2/ >> We were talking about servers. > And if you think a supercomputer isn't a server (or more properly, a collection > of servers), you've not been paying attention. Not necessarily.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-08-07 19:58 +0000 |
| Message-ID | <slrnqkmbb0.cdo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #67381 |
On Wed, 2019-08-07, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: ... >>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. >> > >>Other cpu designs do not attempt to copy the x86. > > Certainly not the instruction set, unless you consider AMD, Cyrix, > Nat Semi, Harris, IBM, TI or Transmeta :-) > > On the other hand, any processor vendor attempting to make a competing > server processor will have to accomodate the standard programming > methods used on Intel processors if they want to gain any market share > since most of the software would be ported from X86. That means things > like unaligned accesses Why would they want that to work? With C or C++ code you can only provoke an unaligned access by writing broken code. Also, the huge body of Unix software is already free from such code (or it wouldn't have worked on e.g. SPARC or PPC). > and providing something that looks like the intel strongly (program) > ordered memory model are high on the desirable feature list. That I can believe, since most people didn't play with such things until long after x86 won dominance. I've written (and been told to write) application code which relied on the x86 model in that area. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 22:08 +0200 |
| Message-ID | <qifb38$n7h$1@news.albasani.net> |
| In reply to | #67396 |
> Why would they want that to work? With C or C++ code you can only > provoke an unaligned access by writing broken code. It's only broken in theory. In reality it will work on most platforms, although it might not be recommended on those emulating ualinged loads / stores through trapping because that's slow. > Also, the huge body of Unix software is already free from such code > (or it wouldn't have worked on e.g. SPARC or PPC). Linux onj SPARC f.e. emulates unaligned memory-accesses through trapping. With Solaris it depends on how you compile your code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 22:13 +0200 |
| Message-ID | <qifbdo$cj8$1@dont-email.me> |
| In reply to | #67396 |
On 07/08/2019 21:58, Jorgen Grahn wrote: > On Wed, 2019-08-07, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: > ... >>> 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. >>> >> >>> Other cpu designs do not attempt to copy the x86. >> >> Certainly not the instruction set, unless you consider AMD, Cyrix, >> Nat Semi, Harris, IBM, TI or Transmeta :-) >> >> On the other hand, any processor vendor attempting to make a competing >> server processor will have to accomodate the standard programming >> methods used on Intel processors if they want to gain any market share >> since most of the software would be ported from X86. That means things >> like unaligned accesses > > Why would they want that to work? With C or C++ code you can only > provoke an unaligned access by writing broken code. Also, the huge > body of Unix software is already free from such code (or it wouldn't > have worked on e.g. SPARC or PPC). I suppose there are a few things to consider here. One is that C and C++ are not the only languages around - perhaps other languages allow unaligned access as long as the target supports it. The other is that, unfortunately, the programming world is full of people who don't know what they are doing, and there is a lot of badly written code out there. I guess the hardware folks would rather support this broken code than limit their market to higher quality code. > >> and providing something that looks like the intel strongly (program) >> ordered memory model are high on the desirable feature list. > > That I can believe, since most people didn't play with such things > until long after x86 won dominance. I've written (and been told to > write) application code which relied on the x86 model in that area. > Certainly strong memory models can be easier to program than weaker ones.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-08-21 20:26 +0000 |
| Message-ID | <slrnqlra73.cdo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #67396 |
On Wed, 2019-08-07, Jorgen Grahn wrote:
> On Wed, 2019-08-07, Scott Lurndal wrote:
...
>> On the other hand, any processor vendor attempting to make a competing
>> server processor will have to accomodate the standard programming
>> methods used on Intel processors if they want to gain any market share
>> since most of the software would be ported from X86. That means things
>> like unaligned accesses
>
> Why would they want that to work? With C or C++ code you can only
> provoke an unaligned access by writing broken code. Also, the huge
> body of Unix software is already free from such code (or it wouldn't
> have worked on e.g. SPARC or PPC).
Or maybe that should be "/used to/ be free from such code", since I
came across this on debian-devel-announce today:
Aurelien Jarno recently proposed[3] the mips architecture
(supporting 32-bit big-endian MIPS CPUs) for removal and then got
it removed[4] [...] The removal was due to the limited 2GB
virtual address space and because the architecture is one of the
last big-endian architecture Debian supports, the porting effort
became increasingly difficult.
So we may be entering another "all the world's a VAX" period. Oh
well, I'm going to keep writing portable code unless paid not to.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Christopher Collins <ccollins476ad@gmail.com> |
|---|---|
| Date | 2019-08-07 12:50 -0700 |
| Message-ID | <slrnqkmasn.1th.ccollins476ad@pseudoephedrine.nightmare-heaven.no-ip.biz> |
| In reply to | #67377 |
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. If you are willing to tie yourself to gcc or clang (and probably others), you can annotate struct definitions with `__attribute__((packed))`. Then you don't need to manually [un]marshal objects that get sent over the network. If the processor does not support unaligned accesses, then the compiler has to generate the marshalling code, and there is probably no savings in code size. But for processors that support fast unaligned access (e.g., ARM cortex M4), the compiler just pretends the data is aligned. You don't pay the price in code size for [un]marshalling code, and the C code is considerably simpler. [...] Chris
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 22:18 +0200 |
| Message-ID | <qifbmh$edd$1@dont-email.me> |
| In reply to | #67395 |
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. > If > you are willing to tie yourself to gcc or clang (and probably others), > you can annotate struct definitions with `__attribute__((packed))`. > Then you don't need to manually [un]marshal objects that get sent over > the network. If the processor does not support unaligned accesses, then > the compiler has to generate the marshalling code, and there is probably > no savings in code size. But for processors that support fast unaligned > access (e.g., ARM cortex M4), the compiler just pretends the data is > aligned. You don't pay the price in code size for [un]marshalling code, > and the C code is considerably simpler. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-07 22:52 +0100 |
| Message-ID | <bLH2F.488756$YG3.461935@fx16.am4> |
| In reply to | #67401 |
On 07/08/2019 21:18, David Brown 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. You have to keep an eye on what's going on, otherwise you may end up with a struct that needs 65 bytes. Will the compiler say anything about that, or just accept it, and try and create arrays with a stride of 65 bytes, or pad them to 128 bytes? I doubt it will re-design the struct to keep it to a power-of-two. > 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. (I've had silent problems with 'pack(1)', where int* accesses that I knew were aligned, were assumed to be unaligned by gcc, and generated byte-at-a-time accesses, which in that app slowed things down to 1/3 the expected speed. Another reason to keep a check on what it is doing.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-08-07 17:52 -0700 |
| Message-ID | <ln36ica37v.fsf@kst-u.example.com> |
| In reply to | #67409 |
Bart <bc@freeuk.com> writes:
[...]
> You have to keep an eye on what's going on, otherwise you may end up
> with a struct that needs 65 bytes. Will the compiler say anything about
> that, or just accept it, and try and create arrays with a stride of 65
> bytes, or pad them to 128 bytes?
>
> I doubt it will re-design the struct to keep it to a power-of-two.
[...]
If the target imposes alignment constraints and you don't use any
compiler extensions to force packing, the compiler will do what it needs
to do to prevent unaligned access. There's unlikely to be any need to
pad a 65-byte structure to 128 bits. It would probably just be padded
to 68 or perhaps 72 bytes, depending on the alignment requirements of
its members.
For example:
#include <stdio.h>
#include <stdint.h>
int main(void) {
struct foo {
uint32_t arr[16];
char c;
};
struct bar {
uint64_t arr[8];
char c;
};
printf("struct foo is %zu bytes\n", sizeof (struct foo));
printf("struct bar is %zu bytes\n", sizeof (struct bar));
}
On my system:
struct foo is 68 bytes
struct bar is 72 bytes
The stride of an array of FOO is always equal to sizeof (FOO); there is
no padding between array elements.
--
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:39 +0200 |
| Message-ID | <qign4s$bqv$1@dont-email.me> |
| In reply to | #67409 |
On 07/08/2019 23:52, Bart wrote:
> On 07/08/2019 21:18, David Brown 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.
>
> You have to keep an eye on what's going on, otherwise you may end up
> with a struct that needs 65 bytes. Will the compiler say anything about
> that, or just accept it, and try and create arrays with a stride of 65
> bytes, or pad them to 128 bytes?
>
> I doubt it will re-design the struct to keep it to a power-of-two.
I don't see much connection between struct sizes and what we have
discussing, but I will try to answer anyway.
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. And you won't get that unless the
component fields have alignments 1, 5 or 13. (I don't know any
platforms with types of alignment 5 or 13, but it is hypothetically
possible.)
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");
or for C18, you might prefer just:
_Static_assert(sizeof(struct X) == 65)
Prior to C11, you can force compile-time errors with declarations like this:
#define STATIC_ASSERT(claim) \
typedef struct { char STATIC_ASSERT_(__LINE__) [ \
(claim) ? 1 : -1]; } STATIC_ASSERT___LINE__)
STATIC_ASSERT(sizeof(struct X) == 65);
Yes, the macro is a little ugly and the error message on failures
complains about array types of negative sizes, but it works nicely, can
be put at file scope or inside a function, and generates no extra code,
data space, or external symbols.
>
>> 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.
>
> (I've had silent problems with 'pack(1)', where int* accesses that I
> knew were aligned, were assumed to be unaligned by gcc, and generated
> byte-at-a-time accesses, which in that app slowed things down to 1/3 the
> expected speed. Another reason to keep a check on what it is doing.)
>
Don't use "packed" attributes or pragmas unless you have to. One
disadvantage is that you lose alignment information and, depending on
the compiler, flags and target, you might get inefficient code such as
the byte-at-a-time accesses you mentioned. 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.
2. Add an attribute "aligned" to the type or variable to tell the
compiler about the struct's alignment. It will figure out the alignment
of the fields from there.
3. Use C11's _Alignas to get the same effect.
4. Wrap the packed struct in a union with a field that has the alignment
you want. Then use that outer union type rather than the struct type,
and the internal struct will have the biggest alignment of the union fields.
5. Use gcc's __builtin_assume_aligned() function when accessing members.
This would quickly make the code quite ugly, but it is the most
flexible as you can tell the compiler that a pointer is, for example, 3
bytes away from 8 byte alignment.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-08-08 13:48 +0100 |
| Message-ID | <RSU2F.718$QR4.98@fx01.am4> |
| In reply to | #67432 |
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.
That can include deliberately using some misalignment although usually
you will try and avoid that.
> 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.
(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.)
> 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.
> 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).
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web