When doing some tests with my ARM64 code generator, I saw the
performances of my software drop from 75% of gcc's speed to just 60%.
What was happening?
One of the reasons (besides the nullity of my code generator of course)
was that gcc cached the values of the global "table" in registers,
re
* jacob navia:
>
> One of the reasons (besides the nullity of my code generator of course)
> was that gcc cached the values of the global "table" in registers,
> reading it just once. Since there are many accesses in the most busy
> function in the program, gcc speeds up considerably.
>
> Cleve
On Sun, Nov 05, 2017 at 08:30:01PM +0100, jacob navia wrote:
> Suppose (one of the multiple scenarios) that you store in a set of memory
> locations data like wind speed, temperature, etc. Only the thread that
> updates that table acquires a lock. All others access the data without any
> locks in r
Le 05/11/2017 à 20:43, Jakub Jelinek a écrit :
A bug in the program that does that. You can use volatile, or atomics
(including e.g. relaxed __atomic_load, which isn't really expensive).
Yeah true. Maybe I will cache them in registers too, it is not very
difficult. Still, I think I will do i
Hi Martin,
On Tue, 31 Oct 2017, KoDDoS Mirror wrote:
> We would like to create a new mirror for GCC in Dronten, Netherlands.
>
> Can you let us know how to process?
you can just ahead, and let us know (ideally with a patch against
http://gcc.gnu.org/mirrors.html ); that's all then. :-)
Cheers,
Snapshot gcc-8-20171105 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20171105/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision
