RE: [PATCH v2] libgfortran: Replace mutex with rwlock

[Zhu, Lipeng via Gcc-patches]

> > Hi Lipeng,
> > 
> > > This patch try to introduce the rwlock and split the read/write to 
> > > unit_root tree and unit_cache with rwlock instead of the mutex to 
> > > increase CPU efficiency. In the get_gfc_unit function, the 
> > > percentage to step into the insert_unit function is around 30%, in 
> > > most instances, we can get the unit in the phase of reading the 
> > > unit_cache or unit_root tree. So split the read/write phase by 
> > > rwlock would be an approach to make it more parallel.
> >
> > No comment on the code itself, as yet... but I'd like to know how 
> > throroughly you tested it, using which tools, and on which programs.
> > Did you use valgrind --tool=helgrind or --tool=drd?  Since it is prone to 
> > race conditions, did you also test Fortran's asynchronous I/O?
> >
> > Best regards
> >
> > Thomas
> 
> Hi Thomas,
> 
> I didn’t use valgrind and make check-fortran succeed in local. 
> And the tools/programs I used is pts/neatbench 
> https://openbenchmarking.org/test/pts/neatbench
> 
> Best Regards,
> Lipeng Zhu

Hi Thomas,

Thanks for your comments, I just use valgrind --tool=helgrind or --tool=drd to 
test make check-fortran, no errors occurred.
==2609780== Helgrind, a thread error detector
==2609780== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al.
==2609780== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2609780== Command: make check-fortran -j150
==2609780==
==2609780==
==2609780== Use --history-level=approx or =none to gain increased speed, at
==2609780== the cost of reduced accuracy of conflicting-access information
==2609780== For lists of detected and suppressed errors, rerun with: -s
==2609780== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

==2976599== drd, a thread error detector
==2976599== Copyright (C) 2006-2020, and GNU GPL'd, by Bart Van Assche.
==2976599== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2976599== Command: make check-fortran -j150
==2976599==
==2976599==
==2976599== For lists of detected and suppressed errors, rerun with: -s
==2976599== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

BTW, can you give me some guidance of how to test Fortran's asynchronous I/O?

Best Regards,
Lipeng Zhu

RE: [PATCH v2] libgfortran: Replace mutex with rwlock

[Zhu, Lipeng via Gcc-patches]

> Hi Lipeng,

> > This patch try to introduce the rwlock and split the read/write to 
> > unit_root tree and unit_cache with rwlock instead of the mutex to 
> > increase CPU efficiency. In the get_gfc_unit function, the percentage 
> > to step into the insert_unit function is around 30%, in most 
> > instances, we can get the unit in the phase of reading the unit_cache 
> > or unit_root tree. So split the read/write phase by rwlock would be an 
> > approach to make it more parallel.
>
> No comment on the code itself, as yet... but I'd like to know how throroughly 
> you tested it, using which tools, and on which programs.
> Did you use valgrind --tool=helgrind or --tool=drd?  Since it is prone to 
> race conditions, did you also test Fortran's asynchronous I/O?
>
> Best regards
>
>   Thomas

Hi Thomas,

I didn’t use valgrind and make check-fortran succeed in local. 
And the tools/programs I used is pts/neatbench 
https://openbenchmarking.org/test/pts/neatbench

Best Regards,
Lipeng Zhu

Re: [PATCH v2] libgfortran: Replace mutex with rwlock

[Thomas Koenig via Gcc-patches]

Hi Lipeng,


This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency. In the get_gfc_unit function, the percentage
to step into the insert_unit function is around 30%, in most instances,
we can get the unit in the phase of reading the unit_cache or unit_root
tree. So split the read/write phase by rwlock would be an approach to
make it more parallel.


No comment on the code itself, as yet... but I'd like to know how
throroughly you tested it, using which tools, and on which programs.
Did you use valgrind --tool=helgrind or --tool=drd?  Since it is
prone to race conditions, did you also test Fortran's asynchronous I/O?

Best regards

Thomas