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 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 10:07 +0200 |
| Message-ID | <qie0so$8la$2@news.albasani.net> |
| In reply to | #67350 |
> https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers Why is this necessary? We have M(O)ESI.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 20:55 -0700 |
| Message-ID | <qig6fi$cn5$1@gioia.aioe.org> |
| In reply to | #67357 |
On 8/7/2019 1:07 AM, Bonita Montero wrote: >> https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers > > > Why is this necessary? We have M(O)ESI. The inherent acquire and release wrt loads and stores on Intel is simply not strong enough to get hazard points up and running. Think about it. Loading/Storing from memory into a local variable implies acquire/release semantics wrt a MOV instruction. Iirc, its in WB memory, or something. so, this is not strong enough for SMR, or Safe Memory Reclamation, aka: Hazard Pointers. Intel is NOT seq_cst... ;^) SMR needs to load back a value _after_ the previous store obtained real data. Intel does NOT allow for this without an explicit fence. A store followed by a load to another location, can and will be reordered. Well, this is not Kosher wrt SMR! load from A store A in B load from A does A == B? the store of A into B needs to be _committed_ before the subsequent load from A. This can use MFENCE or a LOCK prefix wrt a "dummy" RMW, or even directly. So: load from A store A in B MFENCE load from A does A == B This is an explicit memory barrier that needs to be added, even on Intel, believe it or not. Its do to the usage pattern of the algorihtm and the details of Intel.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 08:03 +0200 |
| Message-ID | <qigduu$8p5$1@news.albasani.net> |
| In reply to | #67416 |
If you are doing lock-free synchronizazion and thereby calling FlushProcessWriteBuffers, you've lost anyway. FlushProcessWriteBuffers is a kernel call and slow. If you are doing it that way, you could stick with usual locking and having a better performance.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 23:54 -0700 |
| Message-ID | <qiggui$1o05$1@gioia.aioe.org> |
| In reply to | #67420 |
On 8/7/2019 11:03 PM, Bonita Montero wrote: > If you are doing lock-free synchronizazion and thereby calling > FlushProcessWriteBuffers, you've lost anyway. FlushProcessWriteBuffers > is a kernel call and slow. If you are doing it that way, you could > stick with usual locking and having a better performance. Calls to FlushProcessWriteBuffers are all on the slow side. The slow side of the asymmetric sync, think about it for a moment.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 08:57 +0200 |
| Message-ID | <qidspa$kgb$2@news.albasani.net> |
| In reply to | #67346 |
> Try using unaligned addresses with several threads. That's not relevant to me because I only wanted to measure the cost of an unaligned access. > Try doing a LOCK XADD on a location that straddles two cache > lines, .. That's also not relevant to me; and not only to me because no one would do that in reality because this isn't of any use.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 22:42 -0700 |
| Message-ID | <qigcoq$13uh$2@gioia.aioe.org> |
| In reply to | #67348 |
On 8/6/2019 11:57 PM, Bonita Montero wrote: >> Try using unaligned addresses with several threads. > > That's not relevant to me because I only wanted to measure the > cost of an unaligned access. > >> Try doing a LOCK XADD on a location that straddles two cache >> lines, .. > > That's also not relevant to me; and not only to me because no > one would do that in reality because this isn't of any use. Fair enough.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 14:46 +0000 |
| Message-ID | <hvB2F.154420$ej3.78894@fx36.iad> |
| In reply to | #67346 |
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> writes: >On 8/6/2019 10:13 PM, Bonita Montero wrote: >> I just wrote a litte test that checks the performance of unaligned >> memory-acesses on x86 / Win32. I've run this code on my Ryten 1800X: >> >> I was very surprised that unaligned memory-access is less than twice as >> slow on my PC. >> It would be nice to see results from Intel-CPUs here. Thanks in advance. > >Try using unaligned addresses with several threads. Try doing a LOCK >XADD on a location that straddles two cache lines, and is not aligned on >a line, vs one that is aligned on a cache line, and properly padded. Processor vendors work hard so that most unaligned accesses don't add significant additional latencies to the instructions. Our ARM64 processor generally has no perf difference between aligned and unaligned to DRAM (unaligned isn't supported to device memory). Locked transactions on intel systems that straddle cache lines need to assert a system bus lock, which causes extreme performance degradation, particularly in NUMA systems. Don't do that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 14:09 -0700 |
| Message-ID | <qifelr$1a6c$1@gioia.aioe.org> |
| In reply to | #67371 |
On 8/7/2019 7:46 AM, Scott Lurndal wrote: > "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> writes: >> On 8/6/2019 10:13 PM, Bonita Montero wrote: >>> I just wrote a litte test that checks the performance of unaligned >>> memory-acesses on x86 / Win32. I've run this code on my Ryten 1800X: > >>> >>> I was very surprised that unaligned memory-access is less than twice as >>> slow on my PC. >>> It would be nice to see results from Intel-CPUs here. Thanks in advance. >> >> Try using unaligned addresses with several threads. Try doing a LOCK >> XADD on a location that straddles two cache lines, and is not aligned on >> a line, vs one that is aligned on a cache line, and properly padded. > > Processor vendors work hard so that most unaligned accesses don't add > significant additional latencies to the instructions. Our ARM64 processor > generally has no perf difference between aligned and unaligned to DRAM > (unaligned isn't supported to device memory). > > Locked transactions on intel systems that straddle cache lines need > to assert a system bus lock, which causes extreme performance degradation, > particularly in NUMA systems. Don't do that. > It can be "abused" to achieve userspace asymmetric sync algorithms, or even RCU. These hacks of the system bus lock on Intel are _not_ frequently called, it would make no sense if they were. They are there to force a system wide memory barrier when, say the garbage in a deferred reclamation system builds up to a limit. Now, Windows kindly offers another way to do this. Its not system wide, but process wide: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers Wrt, asymmetric, think of two things A and B that need to be done. A gets called on a very rapid basis. However, B is not used all that much. We call A the fastpath and B the slowpath. A should be as fast as possible. In fact, we can do it without using any memory barriers at all. When B decides to run, it can execute a system wide quiescence using the Intel hack, or call into FlushProcessWriteBuffers to get all the stores. Then it knows that anything A stored to up to this point is guaranteed to be visible. Think of A and B as being the two sides of a Dekker algorihtm, where A gets used more than B. https://en.wikipedia.org/wiki/Dekker%27s_algorithm
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-08-07 11:00 +0300 |
| Message-ID | <qie0fb$9ch$1@dont-email.me> |
| In reply to | #67345 |
On 7.08.2019 8:13, Bonita Montero wrote:
> I just wrote a litte test that checks the performance of unaligned
> memory-acesses on x86 / Win32. I've run this code on my Ryten 1800X:
>
> #pragma warning(disable: 6387)
> #pragma warning(disable: 6001)
> #pragma warning(disable: 4244)
>
> #include <Windows.h>
> #include <iostream>
> #include <cstdint>
> #include <cstring>
> #include <algorithm>
> #include <intrin.h>
>
> using namespace std;
>
> struct unaligned_uint32
> {
> uint8_t u[sizeof(uint32_t)];
> operator uint32_t();
> unaligned_uint32 &operator = ( uint32_t ui );
> };
>
> inline
> unaligned_uint32::operator uint32_t()
> {
> return ((uint32_t)u[0] | (uint32_t)u[1] << 8) | ((uint32_t)u[2] <<
> 16 | (uint32_t)u[3] << 24);
> }
>
> inline
> unaligned_uint32 &unaligned_uint32::operator = ( uint32_t ui )
> {
> u[0] = (uint8_t)ui;
> u[1] = (uint8_t)(ui << 8);
> u[2] = (uint8_t)(ui << 16);
> u[3] = (uint8_t)(ui << 24);
> return *this;
> }
>
>
> template<typename TUI32>
> void memkill( TUI32 *m, size_t elems );
>
> int main()
> {
> size_t const SIZE = (size_t)1024 * 1024;
> size_t const ELEMS = SIZE / sizeof(uint32_t);
> unsigned const ITERATIONS = 10'000;
> char *m;
> LONGLONG llFreq;
> double freq;
> LONGLONG start, end;
> double seconds;
>
> m = (char *)VirtualAlloc( nullptr, SIZE, MEM_RESERVE | MEM_COMMIT,
> PAGE_READWRITE );
> memset( m, 0, SIZE );
>
> QueryPerformanceFrequency( &(LARGE_INTEGER &)llFreq );
> freq = llFreq;
>
> QueryPerformanceCounter( &(LARGE_INTEGER &)start );
> for( unsigned i = 0; i != ITERATIONS; i++ )
> memkill( (uint32_t *)m, ELEMS );
> QueryPerformanceCounter( &(LARGE_INTEGER &)end );
> seconds = (end - start) / freq;
> cout << "aligned native: " << seconds << endl;
>
> QueryPerformanceCounter( &(LARGE_INTEGER &)start );
> for( unsigned i = 0; i != ITERATIONS; i++ )
> memkill( (uint32_t *)(m + 1), ELEMS - 1 );
> QueryPerformanceCounter( &(LARGE_INTEGER &)end );
> seconds = (end - start) / freq;
> cout << "unaligned native: " << seconds << endl;
>
> QueryPerformanceCounter( &(LARGE_INTEGER &)start );
> for( unsigned i = 0; i != ITERATIONS; i++ )
> memkill( (unaligned_uint32 *)(m + 1), ELEMS - 1 );
> QueryPerformanceCounter( &(LARGE_INTEGER &)end );
> seconds = (end - start) / freq;
> cout << "unaligned wrapped: " << seconds << endl;
>
> }
>
> template<typename TUI32>
> void memkill( TUI32 *m, size_t elems )
> {
> for_each( m, m + elems, []( TUI32 &e ) { e = (uint32_t)e + 1; } );
> }
>
> As you can see the code also tests accessing unaligned memory unaligned
> with manual shifting of the bytes.
> Here are the results of my 1800X:
>
> aligned native: 0.244328
> unaligned native: 0.437457
> unaligned wrapped: 2.12482
>
> I was very surprised that unaligned memory-access is less than twice as
> slow on my PC.
> It would be nice to see results from Intel-CPUs here. Thanks in advance.
Results from x64 build on Intel Core i7-6600U:
aligned native: 0.30228
unaligned native: 0.31015
unaligned wrapped: 2.64527
Hmm, seems not so unaligned at all... Trying 32-bit build:
aligned native: 0.362762
unaligned native: 0.42812
unaligned wrapped: 2.63736
BTW, it looks to me your code has a buffer overrun bug. Probably won't
affect benchmarks, but still.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 10:03 +0200 |
| Message-ID | <qie0kc$8la$1@news.albasani.net> |
| In reply to | #67355 |
Am 07.08.2019 um 10:00 schrieb Paavo Helde:
> BTW, it looks to me your code has a buffer overrun bug.
> Probably won't affect benchmarks, but still.
No, look at the "- 1"!
memkill( (unaligned_uint32 *)(m + 1), ELEMS - 1 );
Without this the code would touch the next page which is very likely
to be not allocated so that it would crash.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-08-07 11:46 +0300 |
| Message-ID | <qie351$mo4$1@dont-email.me> |
| In reply to | #67356 |
On 7.08.2019 11:03, Bonita Montero wrote: > Am 07.08.2019 um 10:00 schrieb Paavo Helde: > >> BTW, it looks to me your code has a buffer overrun bug. >> Probably won't affect benchmarks, but still. > > No, look at the "- 1"! > > memkill( (unaligned_uint32 *)(m + 1), ELEMS - 1 ); > > Without this the code would touch the next page which is very likely > to be not allocated so that it would crash. I see. It seems I looked only at the first (aligned) call and assumed the test set size would be the same always.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 11:19 +0200 |
| Message-ID | <qie53o$150$1@dont-email.me> |
| In reply to | #67355 |
On 07/08/2019 10:00, Paavo Helde wrote:
> On 7.08.2019 8:13, Bonita Montero wrote:
>> I just wrote a litte test that checks the performance of unaligned
>> memory-acesses on x86 / Win32. I've run this code on my Ryten 1800X:
>>
>> #pragma warning(disable: 6387)
>> #pragma warning(disable: 6001)
>> #pragma warning(disable: 4244)
>>
>> #include <Windows.h>
>> #include <iostream>
>> #include <cstdint>
>> #include <cstring>
>> #include <algorithm>
>> #include <intrin.h>
>>
>> using namespace std;
>>
>> struct unaligned_uint32
>> {
>> uint8_t u[sizeof(uint32_t)];
>> operator uint32_t();
>> unaligned_uint32 &operator = ( uint32_t ui );
>> };
>>
>> inline
>> unaligned_uint32::operator uint32_t()
>> {
>> return ((uint32_t)u[0] | (uint32_t)u[1] << 8) | ((uint32_t)u[2] <<
>> 16 | (uint32_t)u[3] << 24);
>> }
>>
>> inline
>> unaligned_uint32 &unaligned_uint32::operator = ( uint32_t ui )
>> {
>> u[0] = (uint8_t)ui;
>> u[1] = (uint8_t)(ui << 8);
>> u[2] = (uint8_t)(ui << 16);
>> u[3] = (uint8_t)(ui << 24);
>> return *this;
>> }
>>
>>
Can MSVC not turn these into optimised unaligned accesses? gcc and
clang treat them exactly like accesses via a cast to a uint32_t pointer,
except that the behaviour is defined and portable. (On targets that
don't support unaligned access, gcc will access data by bytes.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 13:13 +0200 |
| Message-ID | <qieboq$9sq$1@news.albasani.net> |
| In reply to | #67359 |
> Can MSVC not turn these into optimised unaligned accesses? Do you really think there will be ever a compiler that "optimizes" away the unaligned loads? The compiler won't simply do what I told him by doing that. I bet there won'T be any C/C++-compiler that does this until the eath is burnt by the sun.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 13:29 +0200 |
| Message-ID | <qiecmn$84u$1@dont-email.me> |
| In reply to | #67360 |
On 07/08/2019 13:13, Bonita Montero wrote:
>> Can MSVC not turn these into optimised unaligned accesses?
>
> Do you really think there will be ever a compiler that "optimizes"
> away the unaligned loads? The compiler won't simply do what I told
> him by doing that. I bet there won'T be any C/C++-compiler that does
> this until the eath is burnt by the sun.
#include <stdint.h>
struct unaligned_uint32
{
uint8_t u[sizeof(uint32_t)];
operator uint32_t();
unaligned_uint32 &operator = ( uint32_t ui );
};
unaligned_uint32::operator uint32_t()
{
return ((uint32_t)u[0] | (uint32_t)u[1] << 8) | ((uint32_t)u[2] <<
16 | (uint32_t)u[3] << 24);
}
gcc -O2:
unaligned_uint32::operator unsigned int():
movl (%rdi), %eax
ret
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 14:02 +0200 |
| Message-ID | <qieek7$1k1$1@news.albasani.net> |
| In reply to | #67361 |
> gcc -O2: > unaligned_uint32::operator unsigned int(): > movl (%rdi), %eax > ret The compiler isn't optimizing away an unaligned load here. If rdi is unaligned the load is also.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 14:08 +0200 |
| Message-ID | <qief04$26j$1@news.albasani.net> |
| In reply to | #67362 |
>> unaligned_uint32::operator unsigned int(): >> movl (%rdi), %eax >> ret > The compiler isn't optimizing away an unaligned load here. > If rdi is unaligned the load is also. Sorry, you miss-worded what you'd like to tell. > Can MSVC not turn these into optimised unaligned accesses? ... is not what you'd like to tell. You wanted to tell that the operator is compiled in a way that the shifts and loads are bundled in a single load. So I misunderstood you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 15:57 +0200 |
| Message-ID | <qielbs$nvv$1@dont-email.me> |
| In reply to | #67363 |
On 07/08/2019 14:08, Bonita Montero wrote: >>> unaligned_uint32::operator unsigned int(): >>> movl (%rdi), %eax >>> ret > >> The compiler isn't optimizing away an unaligned load here. >> If rdi is unaligned the load is also. > > Sorry, you miss-worded what you'd like to tell. >> Can MSVC not turn these into optimised unaligned accesses? > ... is not what you'd like to tell. You wanted to tell that the > operator is compiled in a way that the shifts and loads are bundled > in a single load. So I misunderstood you. > I wrote what I intended to write, but you misunderstood. (That happens, sometimes, especially if when you have to work with a second language. It's no problem.) The compiler turns the shift-and-or code into optimised code using an unaligned access. I was surprised that MSVC could not do this optimisation - that compiler is often quite good at optimisations.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-08-07 12:37 +0000 |
| Message-ID | <slrnqklhgn.cdo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #67345 |
On Wed, 2019-08-07, Bonita Montero wrote: > I just wrote a litte test that checks the performance of unaligned > memory-acesses on x86 / Win32. I've run this code on my Ryten 1800X: What's the point of the exercise, in a C++ context? Unaligned access in portable code is always the result of a programming error. /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 14:47 +0200 |
| Message-ID | <qieh9b$r7m$1@news.albasani.net> |
| In reply to | #67365 |
> What's the point of the exercise, in a C++ context? Unaligned access > in portable code is always the result of a programming error. Pure theory. All platforms support unaligned access either directly through the CPU or through trapping by the operating-system (very slow).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-07 16:18 +0200 |
| Message-ID | <qiemk4$1o5$1@dont-email.me> |
| In reply to | #67366 |
On 07/08/2019 14:47, Bonita Montero wrote: >> What's the point of the exercise, in a C++ context? Unaligned access >> in portable code is always the result of a programming error. > > Pure theory. All platforms support unaligned access either directly > through the CPU or through trapping by the operating-system (very slow). No, they don't. Some cpus support direct unaligned accesses. For others, various things could happen. On big OS's, you are likely to get a trap or exception causing the OS to kill your program with a fault - I can't imagine why an OS would bother simulating the unaligned access. On embedded systems, unaligned access may lead to a bus fault of some sort, halting the system or causing a restart. And on some systems that I have used, unaligned access will silently give you muddled reads and corrupting writes. Unaligned access is always an error. Use code with shifts and masks, if you need it, or use memcpy. If your compiler isn't good enough to give you efficient enough code for your needs, get a better compiler.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web