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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 16:53 +0200 |
| Message-ID | <qieolb$79o$1@news.albasani.net> |
| In reply to | #67369 |
For portability-reasons almost any system tries to be comatible to x86-systems for unaligned accesses. But on some exotic systems which don't run a common operating system or none at all you might be right. Unaligned accesses are simply useful for data-structures which are sent over the network or persisted on disk to save the padding bytes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 17:30 +0200 |
| Message-ID | <qieqqb$5cu$1@dont-email.me> |
| In reply to | #67373 |
/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. (An implementation can use it under the hood, when implementing memcpy, or for the kind of optimisations I showed gcc doing. But you don't write unaligned accesses in the source code.) Other cpu designs do not attempt to copy the x86. The great majority of code that is written that is reliant on a processor working like an x86 is written for Windows, and does not need to be portable to anything other than x86. The rest of the programming world is mostly either aimed at reasonable portability, such as across different *nix systems, or targeted at smaller embedded systems. For portable code, you don't care about unaligned accesses because you don't use them in the source code - you only care that the implementation handles your source code efficiently. 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. And for processors that don't support unaligned access in hardware, no one would bother supporting it by software emulation except if it were required for /binary/ compatibility with other processors in the same family. I don't know of any systems where that applies. > But on some exotic systems which > don't run a common operating system or none at all you might be right. These "exotic" systems far and away outnumber the PC's of this world. The programming world does not revolve around x86. > Unaligned accesses are simply useful for data-structures which are > sent over the network or persisted on disk to save the padding bytes. Nonsense. Proper programming is useful for data structures that are sent over the network or are stored on files. Use portable coding, or implementation dependent coding (like "packed" structs), and let the compiler use whatever instructions are supported and most efficient for the platform.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 17:39 +0200 |
| Message-ID | <qierar$1g0$1@news.albasani.net> |
| In reply to | #67377 |
> There is rarely any reason for wanting unaligned access, and > no justification for using it in code that should be portable. I didn't say that it's always good style, but a lot of code relies on it so that most platforms support it through the CPU or the OS. So the code formerly written for x86 will also run without changes. > 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. I'll bet no one would have implemented this on other CPUs if there won't be a lot of code written on x86-machines that relies on this. > These "exotic" systems far and away outnumber the PC's of this world. Most of these trap unaligned acceses through the OS. >> Unaligned accesses are simply useful for data-structures which are >> sent over the network or persisted on disk to save the padding bytes. > Nonsense. Proper programming is useful for data structures that are > sent over the network or are stored on files. Use portable coding, or > implementation dependent coding (like "packed" structs), and let the > compiler use whatever instructions are supported and most efficient > for the platform. That's your taste of proper programming, but not the facts.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 18:12 +0200 |
| Message-ID | <qiet8v$liu$1@dont-email.me> |
| In reply to | #67378 |
On 07/08/2019 17:39, Bonita Montero wrote: >> There is rarely any reason for wanting unaligned access, and >> no justification for using it in code that should be portable. > > I didn't say that it's always good style, but a lot of code relies > on it so that most platforms support it through the CPU or the OS. Any code that relies on this is very badly written. It may be that it is common in the Windows world, where it is clear that many people have quite a poor knowledge of legal C and C++, and little concept or interest in writing clear, safe, and portable code. And it may be that MSVC, knowing that its users are often unaware of the details of their programming languages, is dumbed down to support such broken code. Attempts to use unaligned access on other compilers may fail in unexpected ways due to undefined behaviour. > So the code formerly written for x86 will also run without changes. Again, nonsense. The x86 is quite a "programmer friendly" ISA. It supports unaligned accesses, it has a strong memory model, it has support for many types of atomic operations. People do write code that is dependent on these features, and also dependent on compilers that have extra semantics to support non-portable coding (such as guaranteeing wrapping on signed integer overflow). Code that is written "assuming an x86 processor" will often have strange breakages on other platforms and other compilers - because the code is not portable C or C++. Other processors do not copy these x86 features. These kind of features can often be very expensive to implement (in terms of die size, power consumption, speed, etc.) and only exist in the x86 world because of backwards compatibility with the kind of badly written code that exists in the Windows world. > >> 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. > > I'll bet no one would have implemented this on other CPUs if there > won't be a lot of code written on x86-machines that relies on this. Bet whatever you like. But don't quit your day job. > >> These "exotic" systems far and away outnumber the PC's of this world. > > Most of these trap unaligned acceses through the OS. 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? If not, then I think we can dispense with the fantasy that OS's provide support for unaligned access when the cpu does not. > >>> Unaligned accesses are simply useful for data-structures which are >>> sent over the network or persisted on disk to save the padding bytes. > >> Nonsense. Proper programming is useful for data structures that are >> sent over the network or are stored on files. Use portable coding, or >> implementation dependent coding (like "packed" structs), and let the >> compiler use whatever instructions are supported and most efficient >> for the platform. > > That's your taste of proper programming, but not the facts. > Quote the section in the C++ standards that says unaligned access is allowed in C++, and I'll believe you.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 18:33 +0200 |
| Message-ID | <qieuhm$nrk$1@news.albasani.net> |
| In reply to | #67382 |
> Any code that relies on this is very badly written. Depends on which platforms you target. > It may be that it is common in the Windows world, where it is clear > that many people have quite a poor knowledge of legal C and C++, Unaligned accesses come not by doing straight coding. You must code with special alignment-directives or with pointer-casting. So these developers that use unalignes acesses know what they're doing and they know the target-platforms. > The x86 is quite a "programmer friendly" ISA. It supports unaligned > accesses, it has a strong memory model, it has support for many types > of atomic operations. People do write code that is dependent on these > features, and also dependent on compilers that have extra semantics to > support non-portable coding (such as guaranteeing wrapping on signed > integer overflow). Code that is written "assuming an x86 processor" > will often have strange breakages on other platforms and other compilers > - because the code is not portable C or C++. Maybe it will break because of other features; but the unaligned themselfes accessses are mostly de-facto-portable to the target -platforms. > 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. >> That's your taste of proper programming, but not the facts. > Quote the section in the C++ standards that says unaligned access is > allowed in C++, and I'll believe you. My statement was related to your taste of proper programming and not to the standard. You're simply one of those compulsive and intolerant programmers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 21:32 +0200 |
| Message-ID | <qif8vp$tuu$1@dont-email.me> |
| In reply to | #67383 |
On 07/08/2019 18:33, Bonita Montero wrote: >> Any code that relies on this is very badly written. > > Depends on which platforms you target. No, it does not - unless you a programming for a single compiler and single target for which the compiler documentation clearly says that unaligned accesses are supported. Even then, you will usually need to do something special (like using the "__unaligned" modifier with MSVC). > >> It may be that it is common in the Windows world, where it is clear >> that many people have quite a poor knowledge of legal C and C++, > > Unaligned accesses come not by doing straight coding. You must code > with special alignment-directives or with pointer-casting. So these > developers that use unalignes acesses know what they're doing and > they know the target-platforms. If they use pointer casts to break alignment requirements (or access objects through incompatible types), then clearly they /don't/ know what they are doing as this is very specifically not allowed by the language. > >> The x86 is quite a "programmer friendly" ISA. It supports unaligned >> accesses, it has a strong memory model, it has support for many types >> of atomic operations. People do write code that is dependent on these >> features, and also dependent on compilers that have extra semantics to >> support non-portable coding (such as guaranteeing wrapping on signed >> integer overflow). Code that is written "assuming an x86 processor" >> will often have strange breakages on other platforms and other compilers >> - because the code is not portable C or C++. > > Maybe it will break because of other features; but the unaligned > themselfes accessses are mostly de-facto-portable to the target > -platforms. No, they are not. You are extrapolating from "it seemed to work when I tried it on one compiler without optimisation" to "it works everywhere". That is ridiculous. It is downright scary that someone who thinks of themselves as a serious programmer would write such stuff. > >> 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. You have /no/ concept of what you are talking about. And you have made it perfectly clear that you have no reference or samples - you are making up stuff as you go along. > >>> That's your taste of proper programming, but not the facts. > >> Quote the section in the C++ standards that says unaligned access is >> allowed in C++, and I'll believe you. > > My statement was related to your taste of proper programming and not > to the standard. > > You're simply one of those compulsive and intolerant programmers. I have little tolerance for people who write code that they know is bad. I have no tolerance for people who not only insist that it is good code on their one platform, but think that this means it works everywhere. You appear to have a very serious misunderstanding of how programming and languages work. Understanding the language and writing code that is correct and valid is not a matter of taste.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 22:01 +0200 |
| Message-ID | <qifam8$mg0$1@news.albasani.net> |
| In reply to | #67393 |
>> Depends on which platforms you target. > No, it does not - unless you a programming for a single compiler and > single target for which the compiler documentation clearly says that > unaligned accesses are supported. Even then, you will usually need to > do something special (like using the "__unaligned" modifier with MSVC). No, you don't have to program for a single computer / compiler, but you can do that for multiple platforms if you have their capabilities in mind > If they use pointer casts to break alignment requirements (or access > objects through incompatible types), then clearly they /don't/ know what > they are doing as this is very specifically not allowed by the language. They know what they do since they know their platform. >> Maybe it will break because of other features; but the unaligned >> themselfes accessses are mostly de-facto-portable to the target >> -platforms. > No, they are not. You have to kow the target-platforms. > You are extrapolating from "it seemed to work when I tried it on one > compiler without optimisation" to "it works everywhere". I never said that. I said that you usually have a set of target-patforms that allow unaligned accesses. >> 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. > You have /no/ concept of what you are talking about. And you have made > it perfectly clear that you have no reference or samples - you are > making up stuff as you go along. No argumentation against what I said above. > I have little tolerance for people who write code that they know is bad. IF the discussed codig is bad depends on the target-platform. Usually it will work because either the CPU supports that or the operating-sys- tem traps unaligned accesses; but in the latter case it's very slow and that's just for compatibility and it's not recommended to rely on it for code that has to run fast.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 22:48 +0200 |
| Message-ID | <qifdet$h0q$1@news.albasani.net> |
| In reply to | #67393 |
Consider this code. It compiles on whether certain platforms support
unaligned loads with proper code and without vaguely relying on the
compiler to strip away the assembly of a uint32_t with shifts and
ORs with a single load / store.
#include <cstdint>
#ifdef _MSC_VER
// MSC only works on x86/x64 and ARMv8
#define SUPPORTS_UNALIGNED
#elif(__GNUC__)
#if defined(__x86_64__) || defined(__i386__)
#define SUPPORTS_UNALIGNED
#elif defined(__aarch64__)
#define SUPPORTS_UNALIGNED
#endif
#endif
struct unaligned_uint32
{
union
{
uint8_t ub[sizeof(uint32_t)];
uint32_t u;
} uu;
operator uint32_t();
unaligned_uint32 &operator = ( uint32_t ui );
};
inline
unaligned_uint32::operator uint32_t()
{
#if defined(SUPPORTS_UNALIGNED)
return uu.u;
#else
return ((uint32_t)uu.ub[0] | (uint32_t)uu.ub[1] << 8) |
((uint32_t)uu.ub[2] << 16 | (uint32_t)uu.ub[3] << 24);
#endif
}
inline
unaligned_uint32 &unaligned_uint32::operator = ( uint32_t ui )
{
#if defined(SUPPORTS_UNALIGNED)
uu.u = ui;
return *this;
#else
uu.ub[0] = (uint8_t)ui;
uu.ub[1] = (uint8_t)(ui << 8);
uu.ub[2] = (uint8_t)(ui << 16);
uu.ub[3] = (uint8_t)(ui << 24);
return *this;
#endif
}
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-08-07 23:02 +0100 |
| Message-ID | <20190807230230.a959da017fbca68269f88a8c@cvine--nospam--.freeserve.co.uk> |
| In reply to | #67404 |
On Wed, 7 Aug 2019 22:48:30 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Consider this code. It compiles on whether certain platforms support
> unaligned loads with proper code and without vaguely relying on the
> compiler to strip away the assembly of a uint32_t with shifts and
> ORs with a single load / store.
>
> #include <cstdint>
>
> #ifdef _MSC_VER
> // MSC only works on x86/x64 and ARMv8
> #define SUPPORTS_UNALIGNED
> #elif(__GNUC__)
> #if defined(__x86_64__) || defined(__i386__)
> #define SUPPORTS_UNALIGNED
> #elif defined(__aarch64__)
> #define SUPPORTS_UNALIGNED
> #endif
> #endif
>
> struct unaligned_uint32
> {
> union
> {
> uint8_t ub[sizeof(uint32_t)];
> uint32_t u;
> } uu;
> operator uint32_t();
> unaligned_uint32 &operator = ( uint32_t ui );
> };
>
> inline
> unaligned_uint32::operator uint32_t()
> {
> #if defined(SUPPORTS_UNALIGNED)
> return uu.u;
> #else
> return ((uint32_t)uu.ub[0] | (uint32_t)uu.ub[1] << 8) |
> ((uint32_t)uu.ub[2] << 16 | (uint32_t)uu.ub[3] << 24);
> #endif
> }
>
> inline
> unaligned_uint32 &unaligned_uint32::operator = ( uint32_t ui )
> {
> #if defined(SUPPORTS_UNALIGNED)
> uu.u = ui;
> return *this;
> #else
> uu.ub[0] = (uint8_t)ui;
> uu.ub[1] = (uint8_t)(ui << 8);
> uu.ub[2] = (uint8_t)(ui << 16);
> uu.ub[3] = (uint8_t)(ui << 24);
> return *this;
> #endif
> }
Out of interest, how are you getting an unaligned_uint32 object which is
in fact unaligned for the target in question? A compiler should
construct a union so that it is correctly aligned for all its members,
so what is the actual usage case? (I have not been reading this thread
attentively so it is possible you have already explained this: if so,
I apologize.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 07:43 +0200 |
| Message-ID | <qigcpj$ba8$1@news.albasani.net> |
| In reply to | #67410 |
> Out of interest, how are you getting an unaligned_uint32 object > which is in fact unaligned for the target in question? I also saw that, but I thought that's sufficient for an example and David would be able to think the rest. And even there's a missing directive to enforce unaligned placement: the object might be placed unaligned by casting a pointet; so a missing directive doesn't count.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 22:54 -0700 |
| Message-ID | <qigdeh$18s1$2@gioia.aioe.org> |
| In reply to | #67418 |
On 8/7/2019 10:43 PM, Bonita Montero wrote: >> Out of interest, how are you getting an unaligned_uint32 object >> which is in fact unaligned for the target in question? > > I also saw that, but I thought that's sufficient for an example and > David would be able to think the rest. And even there's a missing > directive to enforce unaligned placement: the object might be placed > unaligned by casting a pointet; so a missing directive doesn't count. Think of unaligned straddling a cache line!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 08:04 +0200 |
| Message-ID | <qige17$8p5$2@news.albasani.net> |
| In reply to | #67419 |
>>> Out of interest, how are you getting an unaligned_uint32 object >>> which is in fact unaligned for the target in question? >> I also saw that, but I thought that's sufficient for an example and >> David would be able to think the rest. And even there's a missing >> directive to enforce unaligned placement: the object might be placed >> unaligned by casting a pointet; so a missing directive doesn't count. > Think of unaligned straddling a cache line! That has nothing to do with Chris or mine statement.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-08 00:16 -0700 |
| Message-ID | <qigi7l$1q23$2@gioia.aioe.org> |
| In reply to | #67421 |
On 8/7/2019 11:04 PM, Bonita Montero wrote: >>>> Out of interest, how are you getting an unaligned_uint32 object >>>> which is in fact unaligned for the target in question? > >>> I also saw that, but I thought that's sufficient for an example and >>> David would be able to think the rest. And even there's a missing >>> directive to enforce unaligned placement: the object might be placed >>> unaligned by casting a pointet; so a missing directive doesn't count. > >> Think of unaligned straddling a cache line! > > That has nothing to do with Chris or mine statement. Ahh shi%. Sorry again. I keep thinking of where unaligned access on x86 wrt LOCK can possibly be "useful".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 09:58 +0200 |
| Message-ID | <qigkmr$v3k$2@dont-email.me> |
| In reply to | #67419 |
On 08/08/2019 07:54, Chris M. Thomasson wrote: > On 8/7/2019 10:43 PM, Bonita Montero wrote: >>> Out of interest, how are you getting an unaligned_uint32 object >>> which is in fact unaligned for the target in question? >> >> I also saw that, but I thought that's sufficient for an example and >> David would be able to think the rest. And even there's a missing >> directive to enforce unaligned placement: the object might be placed >> unaligned by casting a pointet; so a missing directive doesn't count. > > Think of unaligned straddling a cache line! It is not the efficiency that is the main problem here - it is the correctness of the code (or lack thereof).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-08 01:20 -0700 |
| Message-ID | <qigm0c$dei$2@gioia.aioe.org> |
| In reply to | #67430 |
On 8/8/2019 12:58 AM, David Brown wrote: > On 08/08/2019 07:54, Chris M. Thomasson wrote: >> On 8/7/2019 10:43 PM, Bonita Montero wrote: >>>> Out of interest, how are you getting an unaligned_uint32 object >>>> which is in fact unaligned for the target in question? >>> >>> I also saw that, but I thought that's sufficient for an example and >>> David would be able to think the rest. And even there's a missing >>> directive to enforce unaligned placement: the object might be placed >>> unaligned by casting a pointet; so a missing directive doesn't count. >> >> Think of unaligned straddling a cache line! > > It is not the efficiency that is the main problem here - it is the > correctness of the code (or lack thereof). > The unaligned access with LOCK prefix is a total hack to force a bus lock.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 16:47 +0200 |
| Message-ID | <qihcmp$nmc$1@news.albasani.net> |
| In reply to | #67430 |
>> Think of unaligned straddling a cache line! > It is not the efficiency that is the main problem here - it is the > correctness of the code (or lack thereof). If it works as expected depends on the platform.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-08-08 10:29 +0100 |
| Message-ID | <20190808102954.ce4a3245031e083879b2268b@cvine--nospam--.freeserve.co.uk> |
| In reply to | #67418 |
On Thu, 8 Aug 2019 07:43:17 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > > Out of interest, how are you getting an unaligned_uint32 object > > which is in fact unaligned for the target in question? > > I also saw that, but I thought that's sufficient for an example and > David would be able to think the rest. And even there's a missing > directive to enforce unaligned placement: the object might be placed > unaligned by casting a pointet; so a missing directive doesn't count. Yes, it's a good example of how to access an unaligned object assuming your conditionals are right (about which I defer to others): my curiosity was how the union object got to be unaligned in the first place. If you are casting a pointer to get there you are breaching the strict aliasing rules so you have undefined behaviour anyway (although of course some compilers allow it with a suitable compiler flag such as -fno-strict-aliasing). I suppose the other main way of getting an unaligned unaligned_uint32 object would be with placement new, but again placement new gives undefined behaviour if you construct an object using it in incorrectly aligned memory. Of course, malloc() and operator new() guarantee that the memory they provide is correctly aligned for any type that could be constructed in it, so that isn't normally a problem. I guess using placement new with a stack allocated buffer is the problem area you might fall into, but doing that kind of thing makes me really nervous, so I would need to have an very unusual use case. C++ does provide some help: you can I think safely construct an object T in a stack allocated buffer constructed this way: alignas(T) char buffer[sizeof(T)]; You probably know all this. My purpose in reciting it is to indicate how nervous I would be of this kind of code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 16:50 +0200 |
| Message-ID | <qihcqq$nmc$2@news.albasani.net> |
| In reply to | #67434 |
> If you are casting a pointer to get there you are breaching the strict > aliasing rules so you have undefined behaviour anyway (although of > course some compilers allow it with a suitable compiler flag such as > -fno-strict-aliasing). Doesn't matter! My code is written with conditional-compilation for certain platforms where this does work. And it might be extended for other platforms which also work.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-08 17:05 +0200 |
| Message-ID | <qihdo7$27a$1@dont-email.me> |
| In reply to | #67446 |
On 08/08/2019 16:50, Bonita Montero wrote: >> If you are casting a pointer to get there you are breaching the strict >> aliasing rules so you have undefined behaviour anyway (although of >> course some compilers allow it with a suitable compiler flag such as >> -fno-strict-aliasing). > > Doesn't matter! My code is written with conditional-compilation for > certain platforms where this does work. And it might be extended for > other platforms which also work. No - it is written with conditional compilation for platforms where you /think/ it works. Speculation, guesswork and "it seemed okay when I tried it" is not how you should be writing code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 17:33 +0200 |
| Message-ID | <qihfcf$fp3$1@news.albasani.net> |
| In reply to | #67450 |
>> Doesn't matter! My code is written with conditional-compilation for >> certain platforms where this does work. And it might be extended for >> other platforms which also work. > No - it is written with conditional compilation for platforms where you > /think/ it works. Speculation, guesswork and "it seemed okay when I > tried it" is not how you should be writing code. There's no speculation. It works.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web