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 1 of 11 [1] 2 3 … 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 07:13 +0200 |
| Subject | Performance of unaligned memory-accesses |
| Message-ID | <qidmlj$62b$1@news.albasani.net> |
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.
[toc] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-06 23:20 -0700 |
| Message-ID | <qidqih$1r55$1@gioia.aioe.org> |
| In reply to | #67345 |
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:
>
> #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.
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 08:57 +0200 |
| Message-ID | <qidso0$kgb$1@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 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 00:22 -0700 |
| Message-ID | <qidu77$9p3$3@gioia.aioe.org> |
| In reply to | #67347 |
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 to me because no one > would do that in reality because this isn't of any use. Okay. I was just sort of, thinking out loud. Sorry. Fwiw, using LOCK XADD on unaligned address that straddles a cache line can invoke a Bus lock!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 09:26 +0200 |
| Message-ID | <qidue8$fi7$1@news.albasani.net> |
| In reply to | #67349 |
> Fwiw, using LOCK XADD on unaligned address that > straddles a cache line can invoke a Bus lock! It's logical that Intel implemented unaligned loads and stores for backward-compatibility. And these loads / stores are useful for performantly mofifying datastructure for persistence or transmission over the network. So this is clearly an unique advantage of the Intel-Architecture. But for what should an unaligned LOCK * be useful? I can see no sense in that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 00:33 -0700 |
| Message-ID | <qidus3$elv$1@gioia.aioe.org> |
| In reply to | #67351 |
On 8/7/2019 12:26 AM, Bonita Montero wrote: >> Fwiw, using LOCK XADD on unaligned address that >> straddles a cache line can invoke a Bus lock! > > It's logical that Intel implemented unaligned loads and stores > for backward-compatibility. And these loads / stores are useful > for performantly mofifying datastructure for persistence or > transmission over the network. So this is clearly an unique > advantage of the Intel-Architecture. > But for what should an unaligned LOCK * be useful? I can see > no sense in that. > To trigger a full blown bus lock, to be used as a quiescence point in user space RCU. There is an older write up on this, back in 2010: https://blogs.oracle.com/dave/qpi-quiescence I have implemented RCU in userspace before.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 09:52 +0200 |
| Message-ID | <qidvvv$a57$1@news.albasani.net> |
| In reply to | #67352 |
>> It's logical that Intel implemented unaligned loads and stores >> for backward-compatibility. And these loads / stores are useful >> for performantly mofifying datastructure for persistence or >> transmission over the network. So this is clearly an unique >> advantage of the Intel-Architecture. >> But for what should an unaligned LOCK * be useful? I can see >> no sense in that. > To trigger a full blown bus lock, to be used as a quiescence point > in user space RCU. There is an older write up on this, back in 2010: Ok, but's that's extremely exotic. > There are a whole class of exotic asymmetric synchronization > algorithms that can use this. Although, FlushProcessWriteBuffers > can work okay. Do you have a link?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 13:37 -0700 |
| Message-ID | <qifcpr$11qk$1@gioia.aioe.org> |
| In reply to | #67354 |
On 8/7/2019 12:52 AM, Bonita Montero wrote: >>> It's logical that Intel implemented unaligned loads and stores >>> for backward-compatibility. And these loads / stores are useful >>> for performantly mofifying datastructure for persistence or >>> transmission over the network. So this is clearly an unique >>> advantage of the Intel-Architecture. >>> But for what should an unaligned LOCK * be useful? I can see >>> no sense in that. > >> To trigger a full blown bus lock, to be used as a quiescence point >> in user space RCU. There is an older write up on this, back in 2010: > > Ok, but's that's extremely exotic. > > > There are a whole class of exotic asymmetric synchronization > > algorithms that can use this. Although, FlushProcessWriteBuffers > > can work okay. > > Do you have a link? The following link mentions the asymmetric Dekker algorihtm: https://blogs.oracle.com/dave/qpi-quiescence https://cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/1a6535a9-5fe4-418b-ab11-91f1668a5720/File/acfe7384038ac881c1a34cc0cb0b9315/asymmetric_dekker_synchronization_140215.txt The short version: https://preview.tinyurl.com/y4e5forx There is biased locking: https://blogs.oracle.com/dave/biased-locking-in-hotspot One can remove the nasty #StoreLoad membar in hazard pointers: https://patents.google.com/patent/US20040107227A1/en This requires a store load relationship that even Intel does not have. An MFENCE or LOCK RMW is required. Acquiring a hazard pointer basically involves a load, store, load, compare, conditional loop. The store needs to be _before_ the following load. A release membar is not good enough, even on Intel. Keep in mind that Intel can reorder a store followed by a load to another location. http://www.cs.cmu.edu/~410-f10/doc/Intel_Reordering_318147.pdf
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 08:06 +0200 |
| Message-ID | <qige5b$8p5$3@news.albasani.net> |
| In reply to | #67402 |
I don't think FPWB is suitable for lock-free-programming because it a kernel-call and thereby very slow.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-08 08:14 +0200 |
| Message-ID | <qigeka$733$1@news.albasani.net> |
| In reply to | #67422 |
Consider this:
#include <Windows.h>
#include <iostream>
#include <intrin.h>
using namespace std;
int main()
{
unsigned const ROUNDS = 10'000'000;
int64_t start, end;
double ticksPerCall;
start = (int64_t)__rdtsc();
for( unsigned i = 0; i != ROUNDS; ++i )
FlushProcessWriteBuffers();
end = (int64_t)__rdtsc();
ticksPerCall = (end - start) / (double)ROUNDS;
cout << ticksPerCall << endl;
}
This gives about 1.100 clock-cycles per call on mmy 1800.
Even this is not accurate because it might be the base-clock;
that's horrible.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson " <ahh_f_it@crap.nothing> |
|---|---|
| Date | 2019-08-08 00:00 -0700 |
| Message-ID | <qigh9t$f9e$2@dont-email.me> |
| In reply to | #67423 |
On 8/7/2019 11:14 PM, Bonita Montero wrote:
> Consider this:
>
> #include <Windows.h>
> #include <iostream>
> #include <intrin.h>
>
> using namespace std;
>
> int main()
> {
> unsigned const ROUNDS = 10'000'000;
> int64_t start, end;
> double ticksPerCall;
>
> start = (int64_t)__rdtsc();
> for( unsigned i = 0; i != ROUNDS; ++i )
> FlushProcessWriteBuffers();
> end = (int64_t)__rdtsc();
>
> ticksPerCall = (end - start) / (double)ROUNDS;
> cout << ticksPerCall << endl;
> }
>
> This gives about 1.100 clock-cycles per call on mmy 1800.
> Even this is not accurate because it might be the base-clock;
> that's horrible.
FlushProcessWriteBuffers() is called on the slowpath. Did you read my links?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson " <ahh_f_it@crap.nothing> |
|---|---|
| Date | 2019-08-07 23:59 -0700 |
| Message-ID | <qigh8p$f9e$1@dont-email.me> |
| In reply to | #67422 |
On 8/7/2019 11:06 PM, Bonita Montero wrote: > I don't think FPWB is suitable for lock-free-programming because > it a kernel-call and thereby very slow. Abusing the bus lock can create very excellent performance. User space RCU wrt read "mostly" work loads..
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-08-17 22:13 -0700 |
| Message-ID | <qjampt$aaq$1@gioia.aioe.org> |
| In reply to | #67422 |
On 8/7/2019 11:06 PM, Bonita Montero wrote: > I don't think FPWB is suitable for lock-free-programming because > it a kernel-call and thereby very slow. Not true. Think of RCU, how about fast SMR? Btw its not only slow wrt calling into the Kernel. It does something to other processors running threads within the calling processes affinity mask: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers Its used on the slow side of an asymmetric sync algorihtm. Think of optimizing hot paths, at the expense of hitting slow paths with extra work.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 00:35 -0700 |
| Message-ID | <qidv09$elv$2@gioia.aioe.org> |
| In reply to | #67351 |
On 8/7/2019 12:26 AM, Bonita Montero wrote: >> Fwiw, using LOCK XADD on unaligned address that >> straddles a cache line can invoke a Bus lock! > > It's logical that Intel implemented unaligned loads and stores > for backward-compatibility. And these loads / stores are useful > for performantly mofifying datastructure for persistence or > transmission over the network. So this is clearly an unique > advantage of the Intel-Architecture. > But for what should an unaligned LOCK * be useful? I can see > no sense in that. > There are a whole class of exotic asymmetric synchronization algorithms that can use this. Although, FlushProcessWriteBuffers can work okay.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 14:47 +0000 |
| Message-ID | <1wB2F.154421$ej3.6837@fx36.iad> |
| In reply to | #67351 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> Fwiw, using LOCK XADD on unaligned address that >> straddles a cache line can invoke a Bus lock! > >It's logical that Intel implemented unaligned loads and stores >for backward-compatibility. And these loads / stores are useful >for performantly mofifying datastructure for persistence or >transmission over the network. So this is clearly an unique >advantage of the Intel-Architecture. No, it's not unique. See AArch64.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 16:55 +0200 |
| Message-ID | <qieope$79o$2@news.albasani.net> |
| In reply to | #67372 |
>>> Fwiw, using LOCK XADD on unaligned address that >>> straddles a cache line can invoke a Bus lock! >> It's logical that Intel implemented unaligned loads and stores >> for backward-compatibility. And these loads / stores are useful >> for performantly mofifying datastructure for persistence or >> transmission over the network. So this is clearly an unique >> advantage of the Intel-Architecture. > No, it's not unique. See AArch64. Ok, except for atomicity: i.e. loads / stors aren't atomic and atomic RMW-instruction will alway fault.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 15:11 +0000 |
| Message-ID | <LSB2F.154424$ej3.3233@fx36.iad> |
| In reply to | #67374 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Fwiw, using LOCK XADD on unaligned address that
>>>> straddles a cache line can invoke a Bus lock!
>
>>> It's logical that Intel implemented unaligned loads and stores
>>> for backward-compatibility. And these loads / stores are useful
>>> for performantly mofifying datastructure for persistence or
>>> transmission over the network. So this is clearly an unique
>>> advantage of the Intel-Architecture.
>
>> No, it's not unique. See AArch64.
>
>Ok, except for atomicity: i.e. loads / stors aren't atomic and
>atomic RMW-instruction will alway fault.
>
B2.2:
Atomicity is a feature of memory accesses, described as atomic accesses. The Arm architecture description refers to
two types of atomicity, single-copy atomicity and multi-copy atomicity. In the Armv8 architecture, the atomicity
requirements for memory accesses depend on the memory type, and whether the access is explicit or implicit. For
more information, see:
B2.2.1 Requirements for single-copy atomicity
If ARMv8.4-LSE is implemented, all loads and stores are single-copy atomic when the following conditions are
true:
· Accesses are unaligned to their data size but are aligned within a 16-byte quantity that is aligned to 16 bytes.
· Accesses are to Inner Write-Back, Outer Write-Back Normal cacheable memory.
Otherwise it is IMPLEMENTATION DEFINED whether loads and stores are single-copy atomic.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-07 17:41 +0200 |
| Message-ID | <qiereq$1g0$2@news.albasani.net> |
| In reply to | #67376 |
>> Ok, except for atomicity: i.e. loads / stors aren't atomic and >> atomic RMW-instruction will alway fault. >> > > B2.2: > ... I mis-worded what I wanted to tell: I simply wanted to say that _unaligned_ loads / stores are not atomic on ARM.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-08-07 15:58 +0000 |
| Message-ID | <UyC2F.154426$ej3.135830@fx36.iad> |
| In reply to | #67379 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Ok, except for atomicity: i.e. loads / stors aren't atomic and >>> atomic RMW-instruction will alway fault. >>> >> >> B2.2: >> ... > >I mis-worded what I wanted to tell: I simply wanted to say that >_unaligned_ loads / stores are not atomic on ARM. > But they are atomic on ARMv8.4. Which is what the text you elided showed.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> |
|---|---|
| Date | 2019-08-07 00:24 -0700 |
| Message-ID | <qidubc$9p3$4@gioia.aioe.org> |
| In reply to | #67347 |
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 to me because no one > would do that in reality because this isn't of any use. Actually, it is of some use. It can trigger a BUS lock. So, one can use it for a forced quiescence period in a RCU algorihtm. Actually, Windows has a nice way to do this without totally abusing x86/64: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web