You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(58) |
Nov
(95) |
Dec
(55) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(205) |
Feb
(106) |
Mar
(36) |
Apr
(25) |
May
(34) |
Jun
(36) |
Jul
(161) |
Aug
(66) |
Sep
(100) |
Oct
(62) |
Nov
(77) |
Dec
(172) |
2003 |
Jan
(101) |
Feb
(202) |
Mar
(191) |
Apr
(97) |
May
(27) |
Jun
(21) |
Jul
(16) |
Aug
(55) |
Sep
(155) |
Oct
(166) |
Nov
(19) |
Dec
(134) |
2004 |
Jan
(569) |
Feb
(367) |
Mar
(81) |
Apr
(62) |
May
(124) |
Jun
(77) |
Jul
(85) |
Aug
(80) |
Sep
(66) |
Oct
(42) |
Nov
(20) |
Dec
(133) |
2005 |
Jan
(192) |
Feb
(143) |
Mar
(183) |
Apr
(128) |
May
(136) |
Jun
(18) |
Jul
(22) |
Aug
(33) |
Sep
(20) |
Oct
(12) |
Nov
(80) |
Dec
(44) |
2006 |
Jan
(42) |
Feb
(38) |
Mar
(17) |
Apr
(112) |
May
(220) |
Jun
(67) |
Jul
(96) |
Aug
(214) |
Sep
(104) |
Oct
(67) |
Nov
(150) |
Dec
(103) |
2007 |
Jan
(111) |
Feb
(50) |
Mar
(113) |
Apr
(19) |
May
(32) |
Jun
(34) |
Jul
(61) |
Aug
(103) |
Sep
(75) |
Oct
(99) |
Nov
(102) |
Dec
(40) |
2008 |
Jan
(86) |
Feb
(56) |
Mar
(104) |
Apr
(50) |
May
(45) |
Jun
(64) |
Jul
(71) |
Aug
(147) |
Sep
(132) |
Oct
(176) |
Nov
(46) |
Dec
(136) |
2009 |
Jan
(159) |
Feb
(136) |
Mar
(188) |
Apr
(189) |
May
(166) |
Jun
(97) |
Jul
(160) |
Aug
(235) |
Sep
(163) |
Oct
(46) |
Nov
(99) |
Dec
(54) |
2010 |
Jan
(104) |
Feb
(121) |
Mar
(153) |
Apr
(75) |
May
(138) |
Jun
(63) |
Jul
(61) |
Aug
(27) |
Sep
(93) |
Oct
(63) |
Nov
(40) |
Dec
(102) |
2011 |
Jan
(52) |
Feb
(26) |
Mar
(61) |
Apr
(27) |
May
(33) |
Jun
(43) |
Jul
(37) |
Aug
(53) |
Sep
(58) |
Oct
(63) |
Nov
(67) |
Dec
(16) |
2012 |
Jan
(97) |
Feb
(34) |
Mar
(6) |
Apr
(18) |
May
(32) |
Jun
(9) |
Jul
(17) |
Aug
(78) |
Sep
(24) |
Oct
(101) |
Nov
(31) |
Dec
(7) |
2013 |
Jan
(44) |
Feb
(35) |
Mar
(59) |
Apr
(17) |
May
(29) |
Jun
(38) |
Jul
(48) |
Aug
(46) |
Sep
(74) |
Oct
(140) |
Nov
(94) |
Dec
(177) |
2014 |
Jan
(94) |
Feb
(74) |
Mar
(75) |
Apr
(63) |
May
(24) |
Jun
(1) |
Jul
(30) |
Aug
(112) |
Sep
(78) |
Oct
(137) |
Nov
(60) |
Dec
(17) |
2015 |
Jan
(128) |
Feb
(254) |
Mar
(273) |
Apr
(137) |
May
(181) |
Jun
(157) |
Jul
(83) |
Aug
(34) |
Sep
(26) |
Oct
(9) |
Nov
(24) |
Dec
(43) |
2016 |
Jan
(94) |
Feb
(77) |
Mar
(83) |
Apr
(19) |
May
(39) |
Jun
(1) |
Jul
(5) |
Aug
(10) |
Sep
(28) |
Oct
(34) |
Nov
(82) |
Dec
(301) |
2017 |
Jan
(53) |
Feb
(50) |
Mar
(11) |
Apr
(15) |
May
(23) |
Jun
(36) |
Jul
(84) |
Aug
(90) |
Sep
(35) |
Oct
(81) |
Nov
(13) |
Dec
(11) |
2018 |
Jan
(15) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(6) |
Jul
(4) |
Aug
(13) |
Sep
(31) |
Oct
(4) |
Nov
(25) |
Dec
(64) |
2019 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
(13) |
Jun
(8) |
Jul
(16) |
Aug
(7) |
Sep
(27) |
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(3) |
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(9) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
|
2022 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(8) |
2023 |
Jan
(6) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(10) |
Jun
(7) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
From: Rafael L. <ra...@la...> - 2024-09-22 07:35:15
|
* Hazen Babcock via Plplot-devel <plp...@li...> [2024-09-21 01:11]: > I'm still waiting for Alan (Irwin) to chime in, but this is looking > less and less likely as time goes by. The last commit by Alan was done in July 2021. Its last post in plplot-devel was done in February 2023. After that, he vanished without sending a retirement message. I hope he is doing well. Alan was the de-facto leader of the project for over two decades. > I still have admin on this project on Sourceforge and can add / remove > developers and / or admins if anyone is really interested in taking > over the project. I probably won't be much help beyond that, I just now > tried to run the tests for this project and realized that I don't even > remember how to do this or where this is documented. The tests are automatically run when the Debian package for PLplot is built, see: https://salsa.debian.org/science-team/plplot/-/tree/master/debian/tests?ref_type=heads This is how I discover new bugs in PLplot, from time to time, when languages evolve. > Also, some of the open merge requests seem to be prior to when Alan > vanished, so it might be worth figuring out why he did not accept them > before merging them. Another question: does anyone know who is behind the domain name plplot.org? In the who.is database, the registrant, administrative, and technical contact information appears as “REDACTED FOR PRIVACY”: https://who.is/whois/plplot.org Best, Rafael |
From: Hazen B. <hba...@ma...> - 2024-09-21 01:11:09
|
On 9/18/24 02:32, Rafael Laboissière wrote: * Orion Poplawski <or...@nw...> [2024-09-13 21:49]: I haven't seen a post on this list from anyone other than me since August 2023. Is it time to consider this project dead? I'm still waiting for Alan (Irwin) to chime in, but this is looking less and less likely as time goes by. I still have admin on this project on Sourceforge and can add / remove developers and / or admins if anyone is really interested in taking over the project. I probably won't be much help beyond that, I just now tried to run the tests for this project and realized that I don't even remember how to do this or where this is documented. Also, some of the open merge requests seem to be prior to when Alan vanished, so it might be worth figuring out why he did not accept them before merging them. -Hazen |
From: Orion P. <or...@nw...> - 2024-09-19 04:02:26
|
On 9/18/24 00:32, Rafael Laboissière wrote: > * Orion Poplawski <or...@nw...> [2024-09-13 21:49]: > >> I haven't seen a post on this list from anyone other than me since >> August 2023. Is it time to consider this project dead? > > I have contributed to PLplot for almost a decade, starting in year 2000. > Even though I ceased to contribute upstream, I still maintain the Debian > packages for PLplot, which are in pretty good shape today: there are no > important bugs filed, and the package builds fine and all tests pass in > the set of official architectures of the Debian distribution (amd64, > arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, and s390x). As > long as the situation remains like that, the package will be kept in > Debian. > > That said, the project seems quite dead upstream. The last commit to the > Git repository was done in May 2023. Besides that, there is a backlog of > 72 bugs and 5 patches in the Tickets session at the SourceForge website. I'm afraid that without at least some active maintainers it will bitrot as languages progress. The most recent issue I ran into was Python 3.13 support. Fortuanately, the fix for that turned out to be pretty simple: https://sourceforge.net/p/plplot/plplot/merge-requests/5/ I package plplot for Fedora, but only as a dependency for gdl, though there are a couple other Fedora packages that I don't maintain that use it as well. gdl has discussed maintaining their own stripped down fork as the changes they have wanted to see incorporated into plplot have not been made, see https://github.com/gnudatalanguage/gdl/issues/1654 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 https://www.nwra.com/ |
From: Rafael L. <ra...@la...> - 2024-09-18 06:57:59
|
* Orion Poplawski <or...@nw...> [2024-09-13 21:49]: > I haven't seen a post on this list from anyone other than me since > August 2023. Is it time to consider this project dead? I have contributed to PLplot for almost a decade, starting in year 2000. Even though I ceased to contribute upstream, I still maintain the Debian packages for PLplot, which are in pretty good shape today: there are no important bugs filed, and the package builds fine and all tests pass in the set of official architectures of the Debian distribution (amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, and s390x). As long as the situation remains like that, the package will be kept in Debian. That said, the project seems quite dead upstream. The last commit to the Git repository was done in May 2023. Besides that, there is a backlog of 72 bugs and 5 patches in the Tickets session at the SourceForge website. That said, the longevity of the project is impressive. According to git log, the initial commit was done by Geoffrey Furnish in 1992 (using CVS at that time). In the initial sources, there were drivers for pen plotters, like HP-7580! [*] Indeed, it seems that PLplot was pen-plotter friendly from the very beginning. Best, Rafael Laboissière [*] https://www.hpmuseum.net/display_item.php?hw=76 |
From: <lis...@ic...> - 2024-09-17 23:27:17
|
I wrote the original Ada bindings which happen to contain numerous convenience extensions. I would hate to see this work die. I am willing to maintain the Ada bindings but I haven’t been aware of any work that needs to be done, while acknowledging that some others have also some of the later Ada work. I have never had any feeling for how many Ada users there are but have been gratified to see one of them comment on the quality of the Ada documentation. BTW, I’m pretty useless when it comes to build issues. Jerry Bauck > On Sep 13, 2024, at 8:49 PM, Orion Poplawski <or...@nw...> wrote: > > I haven't seen a post on this list from anyone other than me since August 2023. Is it time to consider this project dead? > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nw... > Boulder, CO 80301 https://www.nwra.com/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Phil R. <p.d...@gm...> - 2024-09-16 01:22:47
|
I still use plplot for all my plotting. But sadly I ran out of time to work on it as much as I used to. I would be very sad to see it die and I will continue to keep a copy up and running for my own needs, even if it isn't "official". As a C++ coder I'm not sure I could ever even pretend to maintain the huge array of language front ends that plplot has. Even if I had the time. I wonder how many people use the different language bindings and drivers. Phil Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Jonathan Woithe <jw...@ju...> Sent: Monday, September 16, 2024 12:55:14 AM To: Orion Poplawski <or...@nw...> Cc: PLplot development list <Plp...@li...> Subject: Re: [Plplot-devel] Is PLplot dead? On Fri, Sep 13, 2024 at 09:49:56PM -0600, Orion Poplawski wrote: > I haven't seen a post on this list from anyone other than me since August > 2023. Is it time to consider this project dead? Speaking personally, I still have a number of applications which make use of plplot. Plplot provides a very capable plotting system, but I concede that that in 2024 there are many alternatives. This was not the case when plplot was first conceived. The language landscape has also shifted considerably in the last decade; in data science for example, python has become particularly popular. I would be sad to see plplot maintenance stop. However, I am not a core developer and have no right to demand that others support a library just because I personally use it. There is certainly less data analysis software being written in C and C++ these days, which naturally reduces the popularity of something like plplot. This in turn causes a shift in priorities amongst those who previously worked on plplot. While I would like to see the ongoing maintenance of plplot, I totally understand the core developers deem it to be no longer worthwhile. In today's software environment, it would be a justifiable position which I would have no trouble accepting. Regardless of what happens to plplot from here, I would like to express my profound gratitude to all those who contributed to plplot over the years. While I have by no means been a heavy user, plplot has been a very handy tool to have at one's disposal and I have appreciated the work that's gone into developing and maintaining it over the years. Regards jonathan _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Jonathan W. <jw...@ju...> - 2024-09-15 23:55:26
|
On Fri, Sep 13, 2024 at 09:49:56PM -0600, Orion Poplawski wrote: > I haven't seen a post on this list from anyone other than me since August > 2023. Is it time to consider this project dead? Speaking personally, I still have a number of applications which make use of plplot. Plplot provides a very capable plotting system, but I concede that that in 2024 there are many alternatives. This was not the case when plplot was first conceived. The language landscape has also shifted considerably in the last decade; in data science for example, python has become particularly popular. I would be sad to see plplot maintenance stop. However, I am not a core developer and have no right to demand that others support a library just because I personally use it. There is certainly less data analysis software being written in C and C++ these days, which naturally reduces the popularity of something like plplot. This in turn causes a shift in priorities amongst those who previously worked on plplot. While I would like to see the ongoing maintenance of plplot, I totally understand the core developers deem it to be no longer worthwhile. In today's software environment, it would be a justifiable position which I would have no trouble accepting. Regardless of what happens to plplot from here, I would like to express my profound gratitude to all those who contributed to plplot over the years. While I have by no means been a heavy user, plplot has been a very handy tool to have at one's disposal and I have appreciated the work that's gone into developing and maintaining it over the years. Regards jonathan |
From: Jeffrey L. <lay...@gm...> - 2024-09-15 22:53:51
|
I didn't see a response. Do you feel like forking it and start maintaining it? (I'm not capable of that, but I will cheer for you). Jeff <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, Sep 14, 2024 at 12:23 AM Orion Poplawski <or...@nw...> wrote: > I haven't seen a post on this list from anyone other than me since > August 2023. Is it time to consider this project dead? > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nw... > Boulder, CO 80301 https://www.nwra.com/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Orion P. <or...@nw...> - 2024-09-14 04:22:57
|
I haven't seen a post on this list from anyone other than me since August 2023. Is it time to consider this project dead? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 https://www.nwra.com/ |
From: Orion P. <or...@nw...> - 2024-08-13 05:20:53
|
/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_pltr_callback’: /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4065:22: error: implicit declaration of function ‘PyEval_CallObject’; did you mean ‘PyObject_CallObject’? [-Wimplicit-function-declaration] 4065 | result = PyEval_CallObject( python_pltr, arglist ); | ^~~~~~~~~~~~~~~~~ | PyObject_CallObject /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4065:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4065 | result = PyEval_CallObject( python_pltr, arglist ); | ^ /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_f2eval_callback’: [ 45%] Built target x10c /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4114:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4114 | result = PyEval_CallObject( python_f2eval, arglist ); | ^ [ 45%] Linking C executable x14c /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_label_callback’: cd /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/examples/c && /usr/bin/cmake -E cmake_link_script CMakeFiles/x14c.dir/link.txt --verbose=1 /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4158:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4158 | result = PyEval_CallObject( python_label, arglist ); | ^ [ 45%] Linking C executable x08c gmake[2]: Leaving directory '/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build' cd /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/examples/c && /usr/bin/cmake -E cmake_link_script CMakeFiles/x08c.dir/link.txt --verbose=1 /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/drivers/cairo.c: In function ‘plD_eop_xcairo’: /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_ct_callback’: [ 45%] Built target x00c /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/drivers/cairo.c:2088:14: warning: variable ‘aStream’ set but not used [-Wunused-but-set-variable] 2088 | PLCairo *aStream; | ^~~~~~~ /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4215:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4215 | result = PyEval_CallObject( python_ct, arglist ); | ^ /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_mapform_callback’: gmake[2]: Leaving directory '/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build' /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4256:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4256 | result = PyEval_CallObject( python_mapform, arglist ); | ^ looks like that was deprecated in 3.9 and removed in 3.13: https://docs.python.org/3.13/whatsnew/3.13.html#removed-c-apis -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 https://www.nwra.com/ |
From: Orion P. <or...@nw...> - 2024-06-15 20:58:54
|
Fedora rawhide has updated to Python 3.13b2 - plplot fails to build with: [ 48%] Linking C executable x15c cd /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/examples/c && /usr/bin/cmake -E cmake_link_script CMakeFiles/x15c.dir/link.txt --verbose=1 /usr/bin/gcc -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--no-warn-execstack -shared -o mem.so CMakeFiles/mem.dir/mem.c.o -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/qsastime: ../src/libplplot.so.17.0.0 -lm -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/qsastime /usr/bin/gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--no-warn-execstack CMakeFiles/x11c.dir/x11c.c.o -o x11c -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/qsastime ../../src/libplplot.so.17.0.0 -lm -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/qsastime /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_pltr_callback’: /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4060:22: error: implicit declaration of function ‘PyEval_CallObject’; did you mean ‘PyObject_CallObject’? [-Wimplicit-function-declaration] 4060 | result = PyEval_CallObject( python_pltr, arglist ); | ^~~~~~~~~~~~~~~~~ | PyObject_CallObject /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4060:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4060 | result = PyEval_CallObject( python_pltr, arglist ); | ^ [ 48%] Linking C executable x17c /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_f2eval_callback’: /usr/bin/gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -Wl,--no-warn-execstack CMakeFiles/x15c.dir/x15c.c.o -o x15c -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/qsastime ../../src/libplplot.so.17.0.0 -lm -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/lib/qsastime /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4109:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4109 | result = PyEval_CallObject( python_f2eval, arglist ); | ^ cd /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/examples/c && /usr/bin/cmake -E cmake_link_script CMakeFiles/x17c.dir/link.txt --verbose=1 /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_label_callback’: /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/drivers/cairo.c: In function ‘plD_eop_xcairo’: /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4153:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4153 | result = PyEval_CallObject( python_label, arglist ); | ^ /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/drivers/cairo.c:2088:14: warning: variable ‘aStream’ set but not used [-Wunused-but-set-variable] 2088 | PLCairo *aStream; | ^~~~~~~ /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_ct_callback’: /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4210:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4210 | result = PyEval_CallObject( python_ct, arglist ); | ^ /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c: In function ‘do_mapform_callback’: [ 48%] Linking C executable pltek /builddir/build/BUILD/plplot-5.15.0-build/plplot-5.15.0/redhat-linux-build/bindings/python/plplotcPYTHON_wrap.c:4251:20: error: assignment to ‘PyObject *’ {aka ‘struct _object *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 4251 | result = PyEval_CallObject( python_mapform, arglist ); According to https://docs.python.org/3.13/whatsnew/3.13.html: Remove PyEval_CallObject(), PyEval_CallObjectWithKeywords(): use PyObject_CallNoArgs() or PyObject_Call() instead. Warning: PyObject_Call() positional arguments must be a tuple and must not be NULL, keyword arguments must be a dict or NULL, whereas removed functions checked arguments type and accepted NULL positional and keyword arguments. To replace PyEval_CallObjectWithKeywords(func, NULL, kwargs) with PyObject_Call(), pass an empty tuple as positional arguments using PyTuple_New(0). -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 https://www.nwra.com/ |
From: Orion P. <or...@nw...> - 2024-03-21 04:21:58
|
Fedora has now started generating errors when code generates an executable stack. This breaks the plplot build: [ 75%] Linking Fortran executable x09f cd /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran && /usr/bin/cmake -E cmake_link_script CMakeFiles/x09f.dir/link.txt --verbose=1 /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer CMakeFiles/x09f.dir/x09f.f90.o -o x09f -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime /usr/bin/ld: error: /tmp/cczNXqc0.ltrans0.ltrans.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) Using -Wtrampolines yields: plplot-5.15.0/examples/fortran/x09f.f90:187:21: warning: trampoline generated for nested function ‘mypltr.3’ [-Wtrampolines] plplot-5.15.0/examples/fortran/x09f.f90:187:21: warning: trampoline generated for nested function ‘mypltr’ [-Wtrampolines] and: /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional09a.adb:92:5: warning: trampoline generated for nested function ‘xtraditional09a.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard09a.adb:92:5: warning: trampoline generated for nested function ‘xstandard09a.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional14a.adb:258:9: warning: trampoline generated for nested function ‘xtraditional14a.plot5.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard14a.adb:258:9: warning: trampoline generated for nested function ‘xstandard14a.plot5.mypltr’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional16a.adb:103:5: warning: trampoline generated for nested function ‘xtraditional16a.zdefined’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard16a.adb:103:5: warning: trampoline generated for nested function ‘xstandard16a.zdefined’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional19a.adb:68:5: warning: trampoline generated for nested function ‘xtraditional19a.map_transform’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional19a.adb:97:5: warning: trampoline generated for nested function ‘xtraditional19a.mapform19’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional19a.adb:124:5: warning: trampoline generated for nested function ‘xtraditional19a.geolocation_labeler’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard19a.adb:68:5: warning: trampoline generated for nested function ‘xstandard19a.map_transform’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard19a.adb:97:5: warning: trampoline generated for nested function ‘xstandard19a.mapform19’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard19a.adb:124:5: warning: trampoline generated for nested function ‘xstandard19a.geolocation_labeler’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xtraditional22a.adb:140:5: warning: trampoline generated for nested function ‘xtraditional22a.transform’ [-Wtrampolines] /home/orion/fedora/plplot/plplot-5.15.0/examples/ada/xstandard22a.adb:140:5: warning: trampoline generated for nested function ‘xstandard22a.transform’ [-Wtrampolines] -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nw... Boulder, CO 80301 https://www.nwra.com/ |
From: Arjen M. <Arj...@de...> - 2023-08-25 06:44:32
|
Hi Jeremy, Thanks for this clarification. None of the options seems really special, but I can imagine that the pkg-config one is the culprit. At least, it is one I have never used myself and pkg-config files are intended to publish information about tools. Regards, Arjen From: Jeremy Nesbitt <jrn...@gm...> Sent: Thursday, August 24, 2023 10:43 PM To: Arjen Markus <Arj...@de...> Cc: plp...@li... Subject: Re: [Plplot-devel] Building plplot in Windows with Intel Fortran Compiler Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment. Hi, Thanks for the reply. Following your note, I did the following: Start the Intel oneAPI Tools command line (installed when I installed their fortran compiler). Go to plplot code and make a build directory. cmake .. When I do this, it finds ifort as the fortran compiler, which meets your expectations. Then I deleted the build folder and started over with all the options I wanted cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON When I did this, cmake found the ifx compiler instead. I know next to nothing about Cmake so my opinion bears little weight, but it seems suspicious that the compiler detection depends on the options I specified. But it was reproducible. When I pass no options, cmake finds ifort first. When I pass the options I want, it finds ifx first. Thanks, Jeremy On Thu, Aug 24, 2023 at 4:04 AM Arjen Markus <Arj...@de...<mailto:Arj...@de...>> wrote: Hi Jeremy, My apologies for not reacting sooner (me being one of the maintainers of PLplot), but at the very least you were able to solve your problem yourself. Could you specify the problems you met with the Intel oneAPI ifx compiler? Intel intends to phase out the classic one at some point in the near future and I was not aware of any problems it might cause. I have not seen any issues with other CMake-enabled builds for Fortran programs. As far as I know CMake picks the classic ifort compiler by default. Regards, Arjen From: Jeremy Nesbitt <jrn...@gm...<mailto:jrn...@gm...>> Sent: Saturday, August 19, 2023 3:30 AM To: plp...@li...<mailto:plp...@li...> Subject: Re: [Plplot-devel] Building plplot in Windows with Intel Fortran Compiler Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment. Hi, I had some time today and figured out the issue. CMake found the Intel IFX compiler first and it seemed to cause confusion about what type of compiler was actually being used. I worked around this by simply using set FC=ifort and re-running CMake. Was able to get everything I wanted built and tested using the command line tools. I'm guessing this is not a common use case, but if it happens to others it might be worth updating the CMake files to handle both the Fortran compilers that are installed from the Intel OneAPI tools. Thanks, Jeremy On Thu, Aug 17, 2023 at 9:10 AM Jeremy Nesbitt <jrn...@gm...<mailto:jrn...@gm...>> wrote: Hi, I would like to get plplot built in windows with intel fortran bindings using the Visual Studio command line. I can get build files generated via CMake if I turn off fortran bindings, but if I enable fortran I always get an error when running CMake. I have tried NMake, Ninja, and Visual Studio 2022 generator files. In initial troubleshooting to see if this is a more general problem, I came across this note on the plplot site: Intel Fortran If you use Intel Fortran, the solution/project files may cause errors when building. These affect only the Fortran libraries and examples. It is due to a small bug in CMake that should be fixed with the next release. Was wondering if anyone had any more information on this, such as what bug it is, what version of CMake it might be fixed in, and whether there is a workaround? I don't know CMake at all, but if I know there is some hope to get tthis working I can give it a shot. Some details if anyone cares: -I am using CMake 3.26-msvc For NMake, used this command cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON Error I get at end -- Configuring done (29.4s) CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): Cannot find source file: plplotfortran.def Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc Call Stack (most recent call first): bindings/fortran/CMakeLists.txt:172 (configure_library_build) CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): No SOURCES given to target: plplotfortran Call Stack (most recent call first): bindings/fortran/CMakeLists.txt:172 (configure_library_build) CMake Generate step failed. Build files cannot be regenerated correctly. ___ What I use for Visual Studio IDE cmake .. -G "Visual Studio 17 2022" -Ax64 -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON Error I get (Truncated as it repeats several times at the end) -- Configuring done (201.6s) CMake Error in bindings/fortran/CMakeLists.txt: Evaluation file to be written multiple times with different content. This is generally caused by the content evaluating the configuration type, language, or location of object files: C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh<http://plplotfortran_ifort.def.sh/> CMake Error in bindings/fortran/CMakeLists.txt: Evaluation file to be written multiple times with different content. This is generally caused by the content evaluating the configuration type, language, or location of object files: C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh<http://plplotfortran_ifort.def.sh/> Thanks, Jeremy DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Jeremy N. <jrn...@gm...> - 2023-08-24 20:43:07
|
Hi, Thanks for the reply. Following your note, I did the following: Start the Intel oneAPI Tools command line (installed when I installed their fortran compiler). Go to plplot code and make a build directory. cmake .. When I do this, it finds ifort as the fortran compiler, which meets your expectations. Then I deleted the build folder and started over with all the options I wanted cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON When I did this, cmake found the ifx compiler instead. I know next to nothing about Cmake so my opinion bears little weight, but it seems suspicious that the compiler detection depends on the options I specified. But it was reproducible. When I pass no options, cmake finds ifort first. When I pass the options I want, it finds ifx first. Thanks, Jeremy On Thu, Aug 24, 2023 at 4:04 AM Arjen Markus <Arj...@de...> wrote: > Hi Jeremy, > > > > My apologies for not reacting sooner (me being one of the maintainers of > PLplot), but at the very least you were able to solve your problem > yourself. Could you specify the problems you met with the Intel oneAPI ifx > compiler? Intel intends to phase out the classic one at some point in the > near future and I was not aware of any problems it might cause. I have not > seen any issues with other CMake-enabled builds for Fortran programs. As > far as I know CMake picks the classic ifort compiler by default. > > > > Regards, > > > > Arjen > > > > *From:* Jeremy Nesbitt <jrn...@gm...> > *Sent:* Saturday, August 19, 2023 3:30 AM > *To:* plp...@li... > *Subject:* Re: [Plplot-devel] Building plplot in Windows with Intel > Fortran Compiler > > > > *Caution:* This message was sent from outside of Deltares. Please do not > click links or open attachments unless you recognize the source of this > email and know the content is safe. Please report all suspicious emails to " > Ser...@de..." as an attachment. > > > > Hi, > > > > I had some time today and figured out the issue. CMake found the Intel > IFX compiler first and it seemed to cause confusion about what type of > compiler was actually being used. I worked around this by simply using set > FC=ifort and re-running CMake. Was able to get everything I wanted built > and tested using the command line tools. > > > > I'm guessing this is not a common use case, but if it happens to others it > might be worth updating the CMake files to handle both the Fortran > compilers that are installed from the Intel OneAPI tools. > > > > Thanks, > > Jeremy > > > > > > > > On Thu, Aug 17, 2023 at 9:10 AM Jeremy Nesbitt <jrn...@gm...> > wrote: > > Hi, > > > > I would like to get plplot built in windows with intel fortran bindings > using the Visual Studio command line. I can get build files generated via > CMake if I turn off fortran bindings, but if I enable fortran I always get > an error when running CMake. I have tried NMake, Ninja, and Visual Studio > 2022 generator files. > > > > In initial troubleshooting to see if this is a more general problem, I > came across this note on the plplot site: > > > > *Intel Fortran* > > If you use Intel Fortran, the solution/project files may cause errors when > building. These affect only the Fortran libraries and examples. It is due > to a small bug in CMake that should be fixed with the next release. > > > > Was wondering if anyone had any more information on this, such as what bug > it is, what version of CMake it might be fixed in, and whether there is a > workaround? I don't know CMake at all, but if I know there is some hope to > get tthis working I can give it a shot. > > > > Some details if anyone cares: > > -I am using CMake 3.26-msvc > > > > For NMake, used this command > > cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON > -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe > -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON > > > > Error I get at end > > -- Configuring done (29.4s) > > CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): > > Cannot find source file: > > > > plplotfortran.def > > > > Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm > .h > > .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc > > Call Stack (most recent call first): > > bindings/fortran/CMakeLists.txt:172 (configure_library_build) > > > > > > CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): > > No SOURCES given to target: plplotfortran > > Call Stack (most recent call first): > > bindings/fortran/CMakeLists.txt:172 (configure_library_build) > > > > > > CMake Generate step failed. Build files cannot be regenerated correctly. > > > > ___ > > > > What I use for Visual Studio IDE > > cmake .. -G "Visual Studio 17 2022" -Ax64 -DBUILD_TEST=ON > -DBUILD_SHARED_LIBS=ON > -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe > -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON > > > > Error I get (Truncated as it repeats several times at the end) > > -- Configuring done (201.6s) > > CMake Error in bindings/fortran/CMakeLists.txt: > > Evaluation file to be written multiple times with different content. > This > > is generally caused by the content evaluating the configuration type, > > language, or location of object files: > > > > C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh > > > > > > CMake Error in bindings/fortran/CMakeLists.txt: > > Evaluation file to be written multiple times with different content. > This > > is generally caused by the content evaluating the configuration type, > > language, or location of object files: > > > > C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh > > > > Thanks, > > Jeremy > > DISCLAIMER: This message is intended exclusively for the addressee(s) and > may contain confidential and privileged information. If you are not the > intended recipient please notify the sender immediately and destroy this > message. Unauthorized use, disclosure or copying of this message is > strictly prohibited. The foundation 'Stichting Deltares', which has its > seat at Delft, The Netherlands, Commercial Registration Number 41146461, is > not liable in any way whatsoever for consequences and/or damages resulting > from the improper, incomplete and untimely dispatch, receipt and/or content > of this e-mail. > |
From: Arjen M. <Arj...@de...> - 2023-08-24 18:40:17
|
Hi Jeremy, My apologies for not reacting sooner (me being one of the maintainers of PLplot), but at the very least you were able to solve your problem yourself. Could you specify the problems you met with the Intel oneAPI ifx compiler? Intel intends to phase out the classic one at some point in the near future and I was not aware of any problems it might cause. I have not seen any issues with other CMake-enabled builds for Fortran programs. As far as I know CMake picks the classic ifort compiler by default. Regards, Arjen From: Jeremy Nesbitt <jrn...@gm...> Sent: Saturday, August 19, 2023 3:30 AM To: plp...@li... Subject: Re: [Plplot-devel] Building plplot in Windows with Intel Fortran Compiler Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment. Hi, I had some time today and figured out the issue. CMake found the Intel IFX compiler first and it seemed to cause confusion about what type of compiler was actually being used. I worked around this by simply using set FC=ifort and re-running CMake. Was able to get everything I wanted built and tested using the command line tools. I'm guessing this is not a common use case, but if it happens to others it might be worth updating the CMake files to handle both the Fortran compilers that are installed from the Intel OneAPI tools. Thanks, Jeremy On Thu, Aug 17, 2023 at 9:10 AM Jeremy Nesbitt <jrn...@gm...<mailto:jrn...@gm...>> wrote: Hi, I would like to get plplot built in windows with intel fortran bindings using the Visual Studio command line. I can get build files generated via CMake if I turn off fortran bindings, but if I enable fortran I always get an error when running CMake. I have tried NMake, Ninja, and Visual Studio 2022 generator files. In initial troubleshooting to see if this is a more general problem, I came across this note on the plplot site: Intel Fortran If you use Intel Fortran, the solution/project files may cause errors when building. These affect only the Fortran libraries and examples. It is due to a small bug in CMake that should be fixed with the next release. Was wondering if anyone had any more information on this, such as what bug it is, what version of CMake it might be fixed in, and whether there is a workaround? I don't know CMake at all, but if I know there is some hope to get tthis working I can give it a shot. Some details if anyone cares: -I am using CMake 3.26-msvc For NMake, used this command cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON Error I get at end -- Configuring done (29.4s) CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): Cannot find source file: plplotfortran.def Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc Call Stack (most recent call first): bindings/fortran/CMakeLists.txt:172 (configure_library_build) CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): No SOURCES given to target: plplotfortran Call Stack (most recent call first): bindings/fortran/CMakeLists.txt:172 (configure_library_build) CMake Generate step failed. Build files cannot be regenerated correctly. ___ What I use for Visual Studio IDE cmake .. -G "Visual Studio 17 2022" -Ax64 -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON Error I get (Truncated as it repeats several times at the end) -- Configuring done (201.6s) CMake Error in bindings/fortran/CMakeLists.txt: Evaluation file to be written multiple times with different content. This is generally caused by the content evaluating the configuration type, language, or location of object files: C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh<http://plplotfortran_ifort.def.sh/> CMake Error in bindings/fortran/CMakeLists.txt: Evaluation file to be written multiple times with different content. This is generally caused by the content evaluating the configuration type, language, or location of object files: C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh<http://plplotfortran_ifort.def.sh/> Thanks, Jeremy DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Jeremy N. <jrn...@gm...> - 2023-08-19 01:30:00
|
Hi, I had some time today and figured out the issue. CMake found the Intel IFX compiler first and it seemed to cause confusion about what type of compiler was actually being used. I worked around this by simply using set FC=ifort and re-running CMake. Was able to get everything I wanted built and tested using the command line tools. I'm guessing this is not a common use case, but if it happens to others it might be worth updating the CMake files to handle both the Fortran compilers that are installed from the Intel OneAPI tools. Thanks, Jeremy On Thu, Aug 17, 2023 at 9:10 AM Jeremy Nesbitt <jrn...@gm...> wrote: > Hi, > > I would like to get plplot built in windows with intel fortran bindings > using the Visual Studio command line. I can get build files generated via > CMake if I turn off fortran bindings, but if I enable fortran I always get > an error when running CMake. I have tried NMake, Ninja, and Visual Studio > 2022 generator files. > > In initial troubleshooting to see if this is a more general problem, I > came across this note on the plplot site: > > *Intel Fortran* > If you use Intel Fortran, the solution/project files may cause errors when > building. These affect only the Fortran libraries and examples. It is due > to a small bug in CMake that should be fixed with the next release. > > Was wondering if anyone had any more information on this, such as what bug > it is, what version of CMake it might be fixed in, and whether there is a > workaround? I don't know CMake at all, but if I know there is some hope to > get tthis working I can give it a shot. > > Some details if anyone cares: > -I am using CMake 3.26-msvc > > For NMake, used this command > cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON > -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe > -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON > > Error I get at end > -- Configuring done (29.4s) > CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): > Cannot find source file: > > plplotfortran.def > > Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm > .h > .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc > Call Stack (most recent call first): > bindings/fortran/CMakeLists.txt:172 (configure_library_build) > > > CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): > No SOURCES given to target: plplotfortran > Call Stack (most recent call first): > bindings/fortran/CMakeLists.txt:172 (configure_library_build) > > > CMake Generate step failed. Build files cannot be regenerated correctly. > > ___ > > What I use for Visual Studio IDE > cmake .. -G "Visual Studio 17 2022" -Ax64 -DBUILD_TEST=ON > -DBUILD_SHARED_LIBS=ON > -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe > -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON > > Error I get (Truncated as it repeats several times at the end) > -- Configuring done (201.6s) > CMake Error in bindings/fortran/CMakeLists.txt: > Evaluation file to be written multiple times with different content. > This > is generally caused by the content evaluating the configuration type, > language, or location of object files: > > C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh > > > CMake Error in bindings/fortran/CMakeLists.txt: > Evaluation file to be written multiple times with different content. > This > is generally caused by the content evaluating the configuration type, > language, or location of object files: > > C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh > > Thanks, > Jeremy > > |
From: Jeremy N. <jrn...@gm...> - 2023-08-17 16:11:09
|
Hi, I would like to get plplot built in windows with intel fortran bindings using the Visual Studio command line. I can get build files generated via CMake if I turn off fortran bindings, but if I enable fortran I always get an error when running CMake. I have tried NMake, Ninja, and Visual Studio 2022 generator files. In initial troubleshooting to see if this is a more general problem, I came across this note on the plplot site: *Intel Fortran* If you use Intel Fortran, the solution/project files may cause errors when building. These affect only the Fortran libraries and examples. It is due to a small bug in CMake that should be fixed with the next release. Was wondering if anyone had any more information on this, such as what bug it is, what version of CMake it might be fixed in, and whether there is a workaround? I don't know CMake at all, but if I know there is some hope to get tthis working I can give it a shot. Some details if anyone cares: -I am using CMake 3.26-msvc For NMake, used this command cmake .. -G "NMake Makefiles" -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON Error I get at end -- Configuring done (29.4s) CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): Cannot find source file: plplotfortran.def Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc Call Stack (most recent call first): bindings/fortran/CMakeLists.txt:172 (configure_library_build) CMake Error at cmake/modules/plplot_functions.cmake:577 (add_library): No SOURCES given to target: plplotfortran Call Stack (most recent call first): bindings/fortran/CMakeLists.txt:172 (configure_library_build) CMake Generate step failed. Build files cannot be regenerated correctly. ___ What I use for Visual Studio IDE cmake .. -G "Visual Studio 17 2022" -Ax64 -DBUILD_TEST=ON -DBUILD_SHARED_LIBS=ON -DPKG_CONFIG_EXECUTABLE=C:\gtk-build\gtk\x64\release\bin\pkg-config.exe -DCMAKE_INSTALL_PREFIX=C:\usr\lib\plplot -DENABLE_fortran=ON Error I get (Truncated as it repeats several times at the end) -- Configuring done (201.6s) CMake Error in bindings/fortran/CMakeLists.txt: Evaluation file to be written multiple times with different content. This is generally caused by the content evaluating the configuration type, language, or location of object files: C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh CMake Error in bindings/fortran/CMakeLists.txt: Evaluation file to be written multiple times with different content. This is generally caused by the content evaluating the configuration type, language, or location of object files: C:/PLplot/build/bindings/fortran/plplotfortran_ifort.def.sh Thanks, Jeremy |
From: Hazen B. <hba...@ma...> - 2023-06-15 20:30:21
|
Hi Phil, Thank you for the clarification. If setting the locale is only important for text rendering, using a period instead of a comma for example, then maybe it would make more sense to guard just the plplot functions that create text? No idea how hard it would be to track down all the functions in the library that might create text such as tick labels, etc. Do you know of a unit test that checks that plplot is actually handling the locale properly? I wasn't able to find one in my searches. -Hazen On 6/14/23 13:33, Phil Rosenberg wrote: > Hi Hazen > Yes, a multiple of around 2.5. > > But for my current scenario, that's the difference between a plot taking > 5-10 minutes to render Vs 15-30 minutes. So it's a big difference. > > Basically the code spends nearly three quarters of its time changing the > locale, and only a quarter of its time rendering. > > But setting/getting the locale is a a file write/read, so it's waaaay > slower than setting a few pixels. > > Phil > > > > Sent from Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------------------------------------------------ > *From:* Hazen Babcock <hba...@ma...> > *Sent:* Wednesday, June 14, 2023 6:03:03 PM > *To:* Phil Rosenberg <p.d...@gm...>; > plp...@li... <plp...@li...> > *Subject:* Re: [Plplot-devel] setlocale > > Hi Phil, > > Can you clarify a bit about the performance difference? Re-reading what > you wrote below I get the impression that just removing the locale calls > alone would only improve things by about 2.5x? Is that correct? > > It sounds like you might have done some profiling, so you might already > have the numbers for memory churn versus the calls to the C locale > function(s)? > > best, > -Hazen > > On 6/13/23 14:15, Phil Rosenberg wrote: >> Hi Hazen >> I hadn't considered what you say about libraries. Let's rule out option 1. >> >> Yes you are correct that drawing large numbers of lines would probably >> have a similar poor performance. >> >> I think the act of checking the locale would be similarly slow. I don't >> think it's memory churn that is causing slowness. I think it's because >> checking and setting the locale involves checking environment variables >> or registry entries. I'm not entirely sure though. >> >> I think if options 1 and 2 are disliked, then option 3 is probably the >> best option. >> >> I can set things up so that the local only gets set for the first >> fill/line and is reset for the last fill/line. >> >> Does that sound okay? >> >> Phil >> >> >> >> Sent from Outlook for Android <https://aka.ms/AAb9ysg <https://aka.ms/AAb9ysg>> >> ------------------------------------------------------------------------ >> *From:* Hazen Babcock <hba...@ma...> >> *Sent:* Tuesday, June 13, 2023 1:31:38 PM >> *To:* Phil Rosenberg <p.d...@gm...>; >> plp...@li... <plp...@li...> >> *Subject:* Re: [Plplot-devel] setlocale >> >> Hi Phil, >> >> I don't think (1) is a good idea. It seems like this only effects >> somewhat extreme plotting situations? Some of the examples also use >> plshade() and they don't seem to be particularly slow. >> >> Alan I think was concerned that the libraries that come with a driver >> might change the locale. The cairo driver for example has a rather large >> library behind it. This library might not change the locale, but it >> would be hard to be sure, and this might change as the library changes. >> >> Also it seems that the overhead of setting and restoring the locale >> would affect any situation with a complicated plot, perhaps most easily >> created using plshades, but if you tried to dray 1M lines you might see >> something similar? So perhaps there are some optimizations that could be >> made instead? For example we could check if the locale was already "C" >> before setting it to "C" and then restoring? We could change >> saved_lc_numerical_locale to a static variable (and not free it in >> plrestore_locale) to reduce the amount of memory churn? We could add a >> compiler flag that makes plsave_set_locale() and plrestore_locale() into >> nops for those who are okay with this? >> >> best, >> -Hazen >> >> On 6/2/23 05:55, Phil Rosenberg wrote: >>> Hi Hazen, Arjen >>> Thanks for the detective work - Alan has used that feature to help me in >>> the past and I had totally forgotten about it. >>> >>> I can see Alan's intention here. In the wxWidgets driver I did similar >>> things with other properties. For example I ensure the device context >>> pen and brush are always set and reset during calls to the driver. This >>> is so that if the user draws to the device context between calls, then >>> plPlot does not cause problems for the user and visa-versa. >>> >>> Setting and resetting the brush was also an expensive operation, so to >>> avoid those calls I have added an escape for starting and stopping >>> plshade. I know that between these escapes there is no need to worry >>> about setting and restoring the state. >>> >>> I think there are a few options, from most intrusive to least intrusive. >>> 1. Undo Alan's work and make it the responsibility of the driver to >>> restore the locale. This is what wxWidgets does with device context brushes. >>> 2. Find where we think the locale might need saving and restoring and >>> only do it for these calls. I'm not sure I like this, as it makes >>> responsibility a grey area. Also I just tried 'ack locale' and 'ack >>> LC_NUMERIC in the src directory and found references only in plargs.c, >>> plcore.c and plctrl.c. So I don't think any drivers do actually change >>> the locale. >>> 3. I can add a variable to the PLStream which records when we enter and >>> leave a plshade call. This can be checked during plfill calls so that >>> only direct plfill calls save and restore the locale. >>> >>> My preference is for 1 or 3, does anyone else have a preference or other >>> thought? 3 is certainly an easier change, but I'm happy to go down >>> another route if people think it will be an improvement. >>> >>> Just to give an idea of the overall benefits here. I'm plotting data on >>> a grid with millions of points. The wxWidgets driver changes I mentioned >>> above and the removal of the locale save/restore and the changes I >>> mentioned a few weeks ago with buffer memory, mean that instead of >>> giving up after plPlot had been rendering for a few hours, the plot is >>> rendered in under 2 minutes. So that's around two orders of magnitude >>> speed increase at least. >>> >>> Phil >>> ------------------------------------------------------------------------ >>> *From:* Arjen Markus <Arj...@de...> >>> *Sent:* Friday, June 2, 2023 7:47:08 AM >>> *To:* Hazen Babcock <hba...@ma...>; >>> plp...@li... <plp...@li...> >>> *Subject:* Re: [Plplot-devel] setlocale >>> Hi Hazen, Phil, >>> >>> If the setting and restoring of the locale takes so much time, then >>> would it be an option to use this only on the plot functions that might >>> actually be affected by the locale? I have only glanced at the code and >>> I have no idea how much work it would be. That would preserve the >>> intended functionality though and get rid of the performance issue. >>> >>> Regards, >>> >>> Arjen >>> |
From: Phil R. <p.d...@gm...> - 2023-06-14 17:33:58
|
Hi Hazen Yes, a multiple of around 2.5. But for my current scenario, that's the difference between a plot taking 5-10 minutes to render Vs 15-30 minutes. So it's a big difference. Basically the code spends nearly three quarters of its time changing the locale, and only a quarter of its time rendering. But setting/getting the locale is a a file write/read, so it's waaaay slower than setting a few pixels. Phil Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Hazen Babcock <hba...@ma...> Sent: Wednesday, June 14, 2023 6:03:03 PM To: Phil Rosenberg <p.d...@gm...>; plp...@li... <plp...@li...> Subject: Re: [Plplot-devel] setlocale Hi Phil, Can you clarify a bit about the performance difference? Re-reading what you wrote below I get the impression that just removing the locale calls alone would only improve things by about 2.5x? Is that correct? It sounds like you might have done some profiling, so you might already have the numbers for memory churn versus the calls to the C locale function(s)? best, -Hazen On 6/13/23 14:15, Phil Rosenberg wrote: > Hi Hazen > I hadn't considered what you say about libraries. Let's rule out option 1. > > Yes you are correct that drawing large numbers of lines would probably > have a similar poor performance. > > I think the act of checking the locale would be similarly slow. I don't > think it's memory churn that is causing slowness. I think it's because > checking and setting the locale involves checking environment variables > or registry entries. I'm not entirely sure though. > > I think if options 1 and 2 are disliked, then option 3 is probably the > best option. > > I can set things up so that the local only gets set for the first > fill/line and is reset for the last fill/line. > > Does that sound okay? > > Phil > > > > Sent from Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------------------------------------------------ > *From:* Hazen Babcock <hba...@ma...> > *Sent:* Tuesday, June 13, 2023 1:31:38 PM > *To:* Phil Rosenberg <p.d...@gm...>; > plp...@li... <plp...@li...> > *Subject:* Re: [Plplot-devel] setlocale > > Hi Phil, > > I don't think (1) is a good idea. It seems like this only effects > somewhat extreme plotting situations? Some of the examples also use > plshade() and they don't seem to be particularly slow. > > Alan I think was concerned that the libraries that come with a driver > might change the locale. The cairo driver for example has a rather large > library behind it. This library might not change the locale, but it > would be hard to be sure, and this might change as the library changes. > > Also it seems that the overhead of setting and restoring the locale > would affect any situation with a complicated plot, perhaps most easily > created using plshades, but if you tried to dray 1M lines you might see > something similar? So perhaps there are some optimizations that could be > made instead? For example we could check if the locale was already "C" > before setting it to "C" and then restoring? We could change > saved_lc_numerical_locale to a static variable (and not free it in > plrestore_locale) to reduce the amount of memory churn? We could add a > compiler flag that makes plsave_set_locale() and plrestore_locale() into > nops for those who are okay with this? > > best, > -Hazen > > On 6/2/23 05:55, Phil Rosenberg wrote: >> Hi Hazen, Arjen >> Thanks for the detective work - Alan has used that feature to help me in >> the past and I had totally forgotten about it. >> >> I can see Alan's intention here. In the wxWidgets driver I did similar >> things with other properties. For example I ensure the device context >> pen and brush are always set and reset during calls to the driver. This >> is so that if the user draws to the device context between calls, then >> plPlot does not cause problems for the user and visa-versa. >> >> Setting and resetting the brush was also an expensive operation, so to >> avoid those calls I have added an escape for starting and stopping >> plshade. I know that between these escapes there is no need to worry >> about setting and restoring the state. >> >> I think there are a few options, from most intrusive to least intrusive. >> 1. Undo Alan's work and make it the responsibility of the driver to >> restore the locale. This is what wxWidgets does with device context brushes. >> 2. Find where we think the locale might need saving and restoring and >> only do it for these calls. I'm not sure I like this, as it makes >> responsibility a grey area. Also I just tried 'ack locale' and 'ack >> LC_NUMERIC in the src directory and found references only in plargs.c, >> plcore.c and plctrl.c. So I don't think any drivers do actually change >> the locale. >> 3. I can add a variable to the PLStream which records when we enter and >> leave a plshade call. This can be checked during plfill calls so that >> only direct plfill calls save and restore the locale. >> >> My preference is for 1 or 3, does anyone else have a preference or other >> thought? 3 is certainly an easier change, but I'm happy to go down >> another route if people think it will be an improvement. >> >> Just to give an idea of the overall benefits here. I'm plotting data on >> a grid with millions of points. The wxWidgets driver changes I mentioned >> above and the removal of the locale save/restore and the changes I >> mentioned a few weeks ago with buffer memory, mean that instead of >> giving up after plPlot had been rendering for a few hours, the plot is >> rendered in under 2 minutes. So that's around two orders of magnitude >> speed increase at least. >> >> Phil >> ------------------------------------------------------------------------ >> *From:* Arjen Markus <Arj...@de...> >> *Sent:* Friday, June 2, 2023 7:47:08 AM >> *To:* Hazen Babcock <hba...@ma...>; >> plp...@li... <plp...@li...> >> *Subject:* Re: [Plplot-devel] setlocale >> Hi Hazen, Phil, >> >> If the setting and restoring of the locale takes so much time, then >> would it be an option to use this only on the plot functions that might >> actually be affected by the locale? I have only glanced at the code and >> I have no idea how much work it would be. That would preserve the >> intended functionality though and get rid of the performance issue. >> >> Regards, >> >> Arjen >> >> -----Original Message----- >> From: Hazen Babcock via Plplot-devel <plp...@li...> >> Sent: Thursday, June 1, 2023 12:57 AM >> To: plp...@li... >> Subject: Re: [Plplot-devel] setlocale >> >> Caution: This message was sent from outside of Deltares. Please do not >> click links or open attachments unless you recognize the source of this >> email and know the content is safe. Please report all suspicious emails >> to "Ser...@de..." as an attachment. >> >> >> Github has an interesting feature which lets you browse the code and see >> the last commit that touched a particular part of the code. Using that >> it looks like saving and restoring the locale was added to the functions >> in src/plcore.c by Alan on Sep 7, 2009. >> >> The commit message: >> """ >> Protect all device driver calls using the (now) reentrant plsave_set_... >> ...locale >> >> and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC >> locale and then sets the LC_NUMERIC locale to "C" for everything done by >> all device drivers. Of course, any library called by a device driver >> can also change the locale, but we guard against such changes affecting >> the rest of PLplot by using plrestore_locale to restore the fundamental >> PLplot LC_NUMERIC locale saved by plsave_set_locale. >> >> N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except >> for the parts like the device drivers and palette file reading that are >> protected by the combination of plsave_set_locale and plrestore_locale) >> to be any valid locale set by any application or library that calls the >> PLplot library. If that locale specifies comma decimal separators >> rather than period decimal separators, for example, then the PLplot core >> will automatically use those for for specifying axis labels. Those >> commas for axis labels are drawn by the PLplot core for the Hershey font >> device drivers or just propagate to the unicode device drivers as UCS4 >> arrays. Thus, in both cases, we get a comma decimal separator for axis >> labels (if that is what the fundamental PLplot LC_NUMERIC locale calls >> for) independently of the logic of the present commit that sets the >> LC_NUMERIC locale to "C" for all device driver code that is executed. >> >> >> svn path=/trunk/; revision=10383 >> """ >> >> -Hazen >> >> On 5/31/23 10:56, Phil Rosenberg wrote: >> > Sorry, I was wrong in my last email - removing the locale calls from >> plP_state as well (used to reset the width after a contour draw within >> plshade) I ended up with a 2.5 times speed increase > > Phil > > On >> Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... >> <mailto:p.d...@gm... <mailto:p.d...@gm... > <mailto:p.d...@gm...>>>> wrote: >> > >> > Hi all >> > I have been making further optimisations to the wxwidgets backen, as >> > I have still been finding it painfully slow for plshade calls. >> > It turned out that almost all the time within the backend (>99%) was >> > spent selecting pens and brushes and allocating memory for every >> > fill within the plshade call. Less that 1% was actually spent within >> > the rendering call to wxWidgets. I have made some good improvements >> > here. >> > >> > However, in addition to this, about 50% of the total execution time >> > is spent in the setlocale function. This is called before and after >> > each polygon fill in the core plplot code. >> > >> > I wondered if anyone really knows the purpose of these calls? >> > Perhaps they are to ensure we have consistent numeric >> > representations across regions? If so, then I don't really >> > understand why they are needed for polygon fills. >> > >> > Any thoughts would be welcome >> > Phil >> > >> > >> > >> > _______________________________________________ >> > Plplot-devel mailing list >> > Plp...@li... >> > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> >> <https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel>> >> >> >> >> On 5/31/23 10:56, Phil Rosenberg wrote: >>> Sorry, I was wrong in my last email - removing the locale calls from >>> plP_state as well (used to reset the width after a contour draw within >>> plshade) I ended up with a 2.5 times speed increase >>> >>> Phil >>> >>> On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... >>> <mailto:p.d...@gm... <mailto:p.d...@gm... > <mailto:p.d...@gm...>>>> wrote: >>> >>> Hi all >>> I have been making further optimisations to the wxwidgets backen, as >>> I have still been finding it painfully slow for plshade calls. >>> It turned out that almost all the time within the backend (>99%) was >>> spent selecting pens and brushes and allocating memory for every >>> fill within the plshade call. Less that 1% was actually spent within >>> the rendering call to wxWidgets. I have made some good improvements >>> here. >>> >>> However, in addition to this, about 50% of the total execution time >>> is spent in the setlocale function. This is called before and after >>> each polygon fill in the core plplot code. >>> >>> I wondered if anyone really knows the purpose of these calls? >>> Perhaps they are to ensure we have consistent numeric >>> representations across regions? If so, then I don't really >>> understand why they are needed for polygon fills. >>> >>> Any thoughts would be welcome >>> Phil >>> >>> >>> >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> https://list/ <https://list/> <https://list/ <https://list/>> >>> s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7Carj >>> en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed >>> 7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb >>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>> %3D%7C3000%7C%7C%7C&sdata=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb >>> 7gY%3D&reserved=0 >> >> >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> >> <https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel>> >> DISCLAIMER: This message is intended exclusively for the addressee(s) >> and may contain confidential and privileged information. If you are not >> the intended recipient please notify the sender immediately and destroy >> this message. Unauthorized use, disclosure or copying of this message is >> strictly prohibited. The foundation 'Stichting Deltares', which has its >> seat at Delft, The Netherlands, Commercial Registration Number 41146461, >> is not liable in any way whatsoever for consequences and/or damages >> resulting from the improper, incomplete and untimely dispatch, receipt >> and/or content of this e-mail. >> >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> >> <https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel>> > |
From: Hazen B. <hba...@ma...> - 2023-06-14 17:03:18
|
Hi Phil, Can you clarify a bit about the performance difference? Re-reading what you wrote below I get the impression that just removing the locale calls alone would only improve things by about 2.5x? Is that correct? It sounds like you might have done some profiling, so you might already have the numbers for memory churn versus the calls to the C locale function(s)? best, -Hazen On 6/13/23 14:15, Phil Rosenberg wrote: > Hi Hazen > I hadn't considered what you say about libraries. Let's rule out option 1. > > Yes you are correct that drawing large numbers of lines would probably > have a similar poor performance. > > I think the act of checking the locale would be similarly slow. I don't > think it's memory churn that is causing slowness. I think it's because > checking and setting the locale involves checking environment variables > or registry entries. I'm not entirely sure though. > > I think if options 1 and 2 are disliked, then option 3 is probably the > best option. > > I can set things up so that the local only gets set for the first > fill/line and is reset for the last fill/line. > > Does that sound okay? > > Phil > > > > Sent from Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------------------------------------------------ > *From:* Hazen Babcock <hba...@ma...> > *Sent:* Tuesday, June 13, 2023 1:31:38 PM > *To:* Phil Rosenberg <p.d...@gm...>; > plp...@li... <plp...@li...> > *Subject:* Re: [Plplot-devel] setlocale > > Hi Phil, > > I don't think (1) is a good idea. It seems like this only effects > somewhat extreme plotting situations? Some of the examples also use > plshade() and they don't seem to be particularly slow. > > Alan I think was concerned that the libraries that come with a driver > might change the locale. The cairo driver for example has a rather large > library behind it. This library might not change the locale, but it > would be hard to be sure, and this might change as the library changes. > > Also it seems that the overhead of setting and restoring the locale > would affect any situation with a complicated plot, perhaps most easily > created using plshades, but if you tried to dray 1M lines you might see > something similar? So perhaps there are some optimizations that could be > made instead? For example we could check if the locale was already "C" > before setting it to "C" and then restoring? We could change > saved_lc_numerical_locale to a static variable (and not free it in > plrestore_locale) to reduce the amount of memory churn? We could add a > compiler flag that makes plsave_set_locale() and plrestore_locale() into > nops for those who are okay with this? > > best, > -Hazen > > On 6/2/23 05:55, Phil Rosenberg wrote: >> Hi Hazen, Arjen >> Thanks for the detective work - Alan has used that feature to help me in >> the past and I had totally forgotten about it. >> >> I can see Alan's intention here. In the wxWidgets driver I did similar >> things with other properties. For example I ensure the device context >> pen and brush are always set and reset during calls to the driver. This >> is so that if the user draws to the device context between calls, then >> plPlot does not cause problems for the user and visa-versa. >> >> Setting and resetting the brush was also an expensive operation, so to >> avoid those calls I have added an escape for starting and stopping >> plshade. I know that between these escapes there is no need to worry >> about setting and restoring the state. >> >> I think there are a few options, from most intrusive to least intrusive. >> 1. Undo Alan's work and make it the responsibility of the driver to >> restore the locale. This is what wxWidgets does with device context brushes. >> 2. Find where we think the locale might need saving and restoring and >> only do it for these calls. I'm not sure I like this, as it makes >> responsibility a grey area. Also I just tried 'ack locale' and 'ack >> LC_NUMERIC in the src directory and found references only in plargs.c, >> plcore.c and plctrl.c. So I don't think any drivers do actually change >> the locale. >> 3. I can add a variable to the PLStream which records when we enter and >> leave a plshade call. This can be checked during plfill calls so that >> only direct plfill calls save and restore the locale. >> >> My preference is for 1 or 3, does anyone else have a preference or other >> thought? 3 is certainly an easier change, but I'm happy to go down >> another route if people think it will be an improvement. >> >> Just to give an idea of the overall benefits here. I'm plotting data on >> a grid with millions of points. The wxWidgets driver changes I mentioned >> above and the removal of the locale save/restore and the changes I >> mentioned a few weeks ago with buffer memory, mean that instead of >> giving up after plPlot had been rendering for a few hours, the plot is >> rendered in under 2 minutes. So that's around two orders of magnitude >> speed increase at least. >> >> Phil >> ------------------------------------------------------------------------ >> *From:* Arjen Markus <Arj...@de...> >> *Sent:* Friday, June 2, 2023 7:47:08 AM >> *To:* Hazen Babcock <hba...@ma...>; >> plp...@li... <plp...@li...> >> *Subject:* Re: [Plplot-devel] setlocale >> Hi Hazen, Phil, >> >> If the setting and restoring of the locale takes so much time, then >> would it be an option to use this only on the plot functions that might >> actually be affected by the locale? I have only glanced at the code and >> I have no idea how much work it would be. That would preserve the >> intended functionality though and get rid of the performance issue. >> >> Regards, >> >> Arjen >> >> -----Original Message----- >> From: Hazen Babcock via Plplot-devel <plp...@li...> >> Sent: Thursday, June 1, 2023 12:57 AM >> To: plp...@li... >> Subject: Re: [Plplot-devel] setlocale >> >> Caution: This message was sent from outside of Deltares. Please do not >> click links or open attachments unless you recognize the source of this >> email and know the content is safe. Please report all suspicious emails >> to "Ser...@de..." as an attachment. >> >> >> Github has an interesting feature which lets you browse the code and see >> the last commit that touched a particular part of the code. Using that >> it looks like saving and restoring the locale was added to the functions >> in src/plcore.c by Alan on Sep 7, 2009. >> >> The commit message: >> """ >> Protect all device driver calls using the (now) reentrant plsave_set_... >> ...locale >> >> and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC >> locale and then sets the LC_NUMERIC locale to "C" for everything done by >> all device drivers. Of course, any library called by a device driver >> can also change the locale, but we guard against such changes affecting >> the rest of PLplot by using plrestore_locale to restore the fundamental >> PLplot LC_NUMERIC locale saved by plsave_set_locale. >> >> N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except >> for the parts like the device drivers and palette file reading that are >> protected by the combination of plsave_set_locale and plrestore_locale) >> to be any valid locale set by any application or library that calls the >> PLplot library. If that locale specifies comma decimal separators >> rather than period decimal separators, for example, then the PLplot core >> will automatically use those for for specifying axis labels. Those >> commas for axis labels are drawn by the PLplot core for the Hershey font >> device drivers or just propagate to the unicode device drivers as UCS4 >> arrays. Thus, in both cases, we get a comma decimal separator for axis >> labels (if that is what the fundamental PLplot LC_NUMERIC locale calls >> for) independently of the logic of the present commit that sets the >> LC_NUMERIC locale to "C" for all device driver code that is executed. >> >> >> svn path=/trunk/; revision=10383 >> """ >> >> -Hazen >> >> On 5/31/23 10:56, Phil Rosenberg wrote: >> > Sorry, I was wrong in my last email - removing the locale calls from >> plP_state as well (used to reset the width after a contour draw within >> plshade) I ended up with a 2.5 times speed increase > > Phil > > On >> Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... >> <mailto:p.d...@gm... <mailto:p.d...@gm... > <mailto:p.d...@gm...>>>> wrote: >> > >> > Hi all >> > I have been making further optimisations to the wxwidgets backen, as >> > I have still been finding it painfully slow for plshade calls. >> > It turned out that almost all the time within the backend (>99%) was >> > spent selecting pens and brushes and allocating memory for every >> > fill within the plshade call. Less that 1% was actually spent within >> > the rendering call to wxWidgets. I have made some good improvements >> > here. >> > >> > However, in addition to this, about 50% of the total execution time >> > is spent in the setlocale function. This is called before and after >> > each polygon fill in the core plplot code. >> > >> > I wondered if anyone really knows the purpose of these calls? >> > Perhaps they are to ensure we have consistent numeric >> > representations across regions? If so, then I don't really >> > understand why they are needed for polygon fills. >> > >> > Any thoughts would be welcome >> > Phil >> > >> > >> > >> > _______________________________________________ >> > Plplot-devel mailing list >> > Plp...@li... >> > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> >> <https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel>> >> >> >> >> On 5/31/23 10:56, Phil Rosenberg wrote: >>> Sorry, I was wrong in my last email - removing the locale calls from >>> plP_state as well (used to reset the width after a contour draw within >>> plshade) I ended up with a 2.5 times speed increase >>> >>> Phil >>> >>> On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... >>> <mailto:p.d...@gm... <mailto:p.d...@gm... > <mailto:p.d...@gm...>>>> wrote: >>> >>> Hi all >>> I have been making further optimisations to the wxwidgets backen, as >>> I have still been finding it painfully slow for plshade calls. >>> It turned out that almost all the time within the backend (>99%) was >>> spent selecting pens and brushes and allocating memory for every >>> fill within the plshade call. Less that 1% was actually spent within >>> the rendering call to wxWidgets. I have made some good improvements >>> here. >>> >>> However, in addition to this, about 50% of the total execution time >>> is spent in the setlocale function. This is called before and after >>> each polygon fill in the core plplot code. >>> >>> I wondered if anyone really knows the purpose of these calls? >>> Perhaps they are to ensure we have consistent numeric >>> representations across regions? If so, then I don't really >>> understand why they are needed for polygon fills. >>> >>> Any thoughts would be welcome >>> Phil >>> >>> >>> >>> _______________________________________________ >>> Plplot-devel mailing list >>> Plp...@li... >>> https://list/ <https://list/> <https://list/ <https://list/>> >>> s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7Carj >>> en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed >>> 7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb >>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >>> %3D%7C3000%7C%7C%7C&sdata=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb >>> 7gY%3D&reserved=0 >> >> >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> >> <https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel>> >> DISCLAIMER: This message is intended exclusively for the addressee(s) >> and may contain confidential and privileged information. If you are not >> the intended recipient please notify the sender immediately and destroy >> this message. Unauthorized use, disclosure or copying of this message is >> strictly prohibited. The foundation 'Stichting Deltares', which has its >> seat at Delft, The Netherlands, Commercial Registration Number 41146461, >> is not liable in any way whatsoever for consequences and/or damages >> resulting from the improper, incomplete and untimely dispatch, receipt >> and/or content of this e-mail. >> >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> >> <https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel>> > |
From: Phil R. <p.d...@gm...> - 2023-06-13 18:15:42
|
Hi Hazen I hadn't considered what you say about libraries. Let's rule out option 1. Yes you are correct that drawing large numbers of lines would probably have a similar poor performance. I think the act of checking the locale would be similarly slow. I don't think it's memory churn that is causing slowness. I think it's because checking and setting the locale involves checking environment variables or registry entries. I'm not entirely sure though. I think if options 1 and 2 are disliked, then option 3 is probably the best option. I can set things up so that the local only gets set for the first fill/line and is reset for the last fill/line. Does that sound okay? Phil Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Hazen Babcock <hba...@ma...> Sent: Tuesday, June 13, 2023 1:31:38 PM To: Phil Rosenberg <p.d...@gm...>; plp...@li... <plp...@li...> Subject: Re: [Plplot-devel] setlocale Hi Phil, I don't think (1) is a good idea. It seems like this only effects somewhat extreme plotting situations? Some of the examples also use plshade() and they don't seem to be particularly slow. Alan I think was concerned that the libraries that come with a driver might change the locale. The cairo driver for example has a rather large library behind it. This library might not change the locale, but it would be hard to be sure, and this might change as the library changes. Also it seems that the overhead of setting and restoring the locale would affect any situation with a complicated plot, perhaps most easily created using plshades, but if you tried to dray 1M lines you might see something similar? So perhaps there are some optimizations that could be made instead? For example we could check if the locale was already "C" before setting it to "C" and then restoring? We could change saved_lc_numerical_locale to a static variable (and not free it in plrestore_locale) to reduce the amount of memory churn? We could add a compiler flag that makes plsave_set_locale() and plrestore_locale() into nops for those who are okay with this? best, -Hazen On 6/2/23 05:55, Phil Rosenberg wrote: > Hi Hazen, Arjen > Thanks for the detective work - Alan has used that feature to help me in > the past and I had totally forgotten about it. > > I can see Alan's intention here. In the wxWidgets driver I did similar > things with other properties. For example I ensure the device context > pen and brush are always set and reset during calls to the driver. This > is so that if the user draws to the device context between calls, then > plPlot does not cause problems for the user and visa-versa. > > Setting and resetting the brush was also an expensive operation, so to > avoid those calls I have added an escape for starting and stopping > plshade. I know that between these escapes there is no need to worry > about setting and restoring the state. > > I think there are a few options, from most intrusive to least intrusive. > 1. Undo Alan's work and make it the responsibility of the driver to > restore the locale. This is what wxWidgets does with device context brushes. > 2. Find where we think the locale might need saving and restoring and > only do it for these calls. I'm not sure I like this, as it makes > responsibility a grey area. Also I just tried 'ack locale' and 'ack > LC_NUMERIC in the src directory and found references only in plargs.c, > plcore.c and plctrl.c. So I don't think any drivers do actually change > the locale. > 3. I can add a variable to the PLStream which records when we enter and > leave a plshade call. This can be checked during plfill calls so that > only direct plfill calls save and restore the locale. > > My preference is for 1 or 3, does anyone else have a preference or other > thought? 3 is certainly an easier change, but I'm happy to go down > another route if people think it will be an improvement. > > Just to give an idea of the overall benefits here. I'm plotting data on > a grid with millions of points. The wxWidgets driver changes I mentioned > above and the removal of the locale save/restore and the changes I > mentioned a few weeks ago with buffer memory, mean that instead of > giving up after plPlot had been rendering for a few hours, the plot is > rendered in under 2 minutes. So that's around two orders of magnitude > speed increase at least. > > Phil > ------------------------------------------------------------------------ > *From:* Arjen Markus <Arj...@de...> > *Sent:* Friday, June 2, 2023 7:47:08 AM > *To:* Hazen Babcock <hba...@ma...>; > plp...@li... <plp...@li...> > *Subject:* Re: [Plplot-devel] setlocale > Hi Hazen, Phil, > > If the setting and restoring of the locale takes so much time, then > would it be an option to use this only on the plot functions that might > actually be affected by the locale? I have only glanced at the code and > I have no idea how much work it would be. That would preserve the > intended functionality though and get rid of the performance issue. > > Regards, > > Arjen > > -----Original Message----- > From: Hazen Babcock via Plplot-devel <plp...@li...> > Sent: Thursday, June 1, 2023 12:57 AM > To: plp...@li... > Subject: Re: [Plplot-devel] setlocale > > Caution: This message was sent from outside of Deltares. Please do not > click links or open attachments unless you recognize the source of this > email and know the content is safe. Please report all suspicious emails > to "Ser...@de..." as an attachment. > > > Github has an interesting feature which lets you browse the code and see > the last commit that touched a particular part of the code. Using that > it looks like saving and restoring the locale was added to the functions > in src/plcore.c by Alan on Sep 7, 2009. > > The commit message: > """ > Protect all device driver calls using the (now) reentrant plsave_set_... > ...locale > > and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC > locale and then sets the LC_NUMERIC locale to "C" for everything done by > all device drivers. Of course, any library called by a device driver > can also change the locale, but we guard against such changes affecting > the rest of PLplot by using plrestore_locale to restore the fundamental > PLplot LC_NUMERIC locale saved by plsave_set_locale. > > N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except > for the parts like the device drivers and palette file reading that are > protected by the combination of plsave_set_locale and plrestore_locale) > to be any valid locale set by any application or library that calls the > PLplot library. If that locale specifies comma decimal separators > rather than period decimal separators, for example, then the PLplot core > will automatically use those for for specifying axis labels. Those > commas for axis labels are drawn by the PLplot core for the Hershey font > device drivers or just propagate to the unicode device drivers as UCS4 > arrays. Thus, in both cases, we get a comma decimal separator for axis > labels (if that is what the fundamental PLplot LC_NUMERIC locale calls > for) independently of the logic of the present commit that sets the > LC_NUMERIC locale to "C" for all device driver code that is executed. > > > svn path=/trunk/; revision=10383 > """ > > -Hazen > > On 5/31/23 10:56, Phil Rosenberg wrote: > > Sorry, I was wrong in my last email - removing the locale calls from > plP_state as well (used to reset the width after a contour draw within > plshade) I ended up with a 2.5 times speed increase > > Phil > > On > Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... > <mailto:p.d...@gm... <mailto:p.d...@gm...>>> wrote: > > > > Hi all > > I have been making further optimisations to the wxwidgets backen, as > > I have still been finding it painfully slow for plshade calls. > > It turned out that almost all the time within the backend (>99%) was > > spent selecting pens and brushes and allocating memory for every > > fill within the plshade call. Less that 1% was actually spent within > > the rendering call to wxWidgets. I have made some good improvements > > here. > > > > However, in addition to this, about 50% of the total execution time > > is spent in the setlocale function. This is called before and after > > each polygon fill in the core plplot code. > > > > I wondered if anyone really knows the purpose of these calls? > > Perhaps they are to ensure we have consistent numeric > > representations across regions? If so, then I don't really > > understand why they are needed for polygon fills. > > > > Any thoughts would be welcome > > Phil > > > > > > > > _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> > > > > On 5/31/23 10:56, Phil Rosenberg wrote: >> Sorry, I was wrong in my last email - removing the locale calls from >> plP_state as well (used to reset the width after a contour draw within >> plshade) I ended up with a 2.5 times speed increase >> >> Phil >> >> On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... >> <mailto:p.d...@gm... <mailto:p.d...@gm...>>> wrote: >> >> Hi all >> I have been making further optimisations to the wxwidgets backen, as >> I have still been finding it painfully slow for plshade calls. >> It turned out that almost all the time within the backend (>99%) was >> spent selecting pens and brushes and allocating memory for every >> fill within the plshade call. Less that 1% was actually spent within >> the rendering call to wxWidgets. I have made some good improvements >> here. >> >> However, in addition to this, about 50% of the total execution time >> is spent in the setlocale function. This is called before and after >> each polygon fill in the core plplot code. >> >> I wondered if anyone really knows the purpose of these calls? >> Perhaps they are to ensure we have consistent numeric >> representations across regions? If so, then I don't really >> understand why they are needed for polygon fills. >> >> Any thoughts would be welcome >> Phil >> >> >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://list/ <https://list/> >> s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7Carj >> en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed >> 7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3D%7C3000%7C%7C%7C&sdata=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb >> 7gY%3D&reserved=0 > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> > DISCLAIMER: This message is intended exclusively for the addressee(s) > and may contain confidential and privileged information. If you are not > the intended recipient please notify the sender immediately and destroy > this message. Unauthorized use, disclosure or copying of this message is > strictly prohibited. The foundation 'Stichting Deltares', which has its > seat at Delft, The Netherlands, Commercial Registration Number 41146461, > is not liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, receipt > and/or content of this e-mail. > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> |
From: Hazen B. <hba...@ma...> - 2023-06-13 12:32:02
|
Hi Phil, I don't think (1) is a good idea. It seems like this only effects somewhat extreme plotting situations? Some of the examples also use plshade() and they don't seem to be particularly slow. Alan I think was concerned that the libraries that come with a driver might change the locale. The cairo driver for example has a rather large library behind it. This library might not change the locale, but it would be hard to be sure, and this might change as the library changes. Also it seems that the overhead of setting and restoring the locale would affect any situation with a complicated plot, perhaps most easily created using plshades, but if you tried to dray 1M lines you might see something similar? So perhaps there are some optimizations that could be made instead? For example we could check if the locale was already "C" before setting it to "C" and then restoring? We could change saved_lc_numerical_locale to a static variable (and not free it in plrestore_locale) to reduce the amount of memory churn? We could add a compiler flag that makes plsave_set_locale() and plrestore_locale() into nops for those who are okay with this? best, -Hazen On 6/2/23 05:55, Phil Rosenberg wrote: > Hi Hazen, Arjen > Thanks for the detective work - Alan has used that feature to help me in > the past and I had totally forgotten about it. > > I can see Alan's intention here. In the wxWidgets driver I did similar > things with other properties. For example I ensure the device context > pen and brush are always set and reset during calls to the driver. This > is so that if the user draws to the device context between calls, then > plPlot does not cause problems for the user and visa-versa. > > Setting and resetting the brush was also an expensive operation, so to > avoid those calls I have added an escape for starting and stopping > plshade. I know that between these escapes there is no need to worry > about setting and restoring the state. > > I think there are a few options, from most intrusive to least intrusive. > 1. Undo Alan's work and make it the responsibility of the driver to > restore the locale. This is what wxWidgets does with device context brushes. > 2. Find where we think the locale might need saving and restoring and > only do it for these calls. I'm not sure I like this, as it makes > responsibility a grey area. Also I just tried 'ack locale' and 'ack > LC_NUMERIC in the src directory and found references only in plargs.c, > plcore.c and plctrl.c. So I don't think any drivers do actually change > the locale. > 3. I can add a variable to the PLStream which records when we enter and > leave a plshade call. This can be checked during plfill calls so that > only direct plfill calls save and restore the locale. > > My preference is for 1 or 3, does anyone else have a preference or other > thought? 3 is certainly an easier change, but I'm happy to go down > another route if people think it will be an improvement. > > Just to give an idea of the overall benefits here. I'm plotting data on > a grid with millions of points. The wxWidgets driver changes I mentioned > above and the removal of the locale save/restore and the changes I > mentioned a few weeks ago with buffer memory, mean that instead of > giving up after plPlot had been rendering for a few hours, the plot is > rendered in under 2 minutes. So that's around two orders of magnitude > speed increase at least. > > Phil > ------------------------------------------------------------------------ > *From:* Arjen Markus <Arj...@de...> > *Sent:* Friday, June 2, 2023 7:47:08 AM > *To:* Hazen Babcock <hba...@ma...>; > plp...@li... <plp...@li...> > *Subject:* Re: [Plplot-devel] setlocale > Hi Hazen, Phil, > > If the setting and restoring of the locale takes so much time, then > would it be an option to use this only on the plot functions that might > actually be affected by the locale? I have only glanced at the code and > I have no idea how much work it would be. That would preserve the > intended functionality though and get rid of the performance issue. > > Regards, > > Arjen > > -----Original Message----- > From: Hazen Babcock via Plplot-devel <plp...@li...> > Sent: Thursday, June 1, 2023 12:57 AM > To: plp...@li... > Subject: Re: [Plplot-devel] setlocale > > Caution: This message was sent from outside of Deltares. Please do not > click links or open attachments unless you recognize the source of this > email and know the content is safe. Please report all suspicious emails > to "Ser...@de..." as an attachment. > > > Github has an interesting feature which lets you browse the code and see > the last commit that touched a particular part of the code. Using that > it looks like saving and restoring the locale was added to the functions > in src/plcore.c by Alan on Sep 7, 2009. > > The commit message: > """ > Protect all device driver calls using the (now) reentrant plsave_set_... > ...locale > > and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC > locale and then sets the LC_NUMERIC locale to "C" for everything done by > all device drivers. Of course, any library called by a device driver > can also change the locale, but we guard against such changes affecting > the rest of PLplot by using plrestore_locale to restore the fundamental > PLplot LC_NUMERIC locale saved by plsave_set_locale. > > N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except > for the parts like the device drivers and palette file reading that are > protected by the combination of plsave_set_locale and plrestore_locale) > to be any valid locale set by any application or library that calls the > PLplot library. If that locale specifies comma decimal separators > rather than period decimal separators, for example, then the PLplot core > will automatically use those for for specifying axis labels. Those > commas for axis labels are drawn by the PLplot core for the Hershey font > device drivers or just propagate to the unicode device drivers as UCS4 > arrays. Thus, in both cases, we get a comma decimal separator for axis > labels (if that is what the fundamental PLplot LC_NUMERIC locale calls > for) independently of the logic of the present commit that sets the > LC_NUMERIC locale to "C" for all device driver code that is executed. > > > svn path=/trunk/; revision=10383 > """ > > -Hazen > > On 5/31/23 10:56, Phil Rosenberg wrote: > > Sorry, I was wrong in my last email - removing the locale calls from > plP_state as well (used to reset the width after a contour draw within > plshade) I ended up with a 2.5 times speed increase > > Phil > > On > Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... > <mailto:p.d...@gm... <mailto:p.d...@gm...>>> wrote: > > > > Hi all > > I have been making further optimisations to the wxwidgets backen, as > > I have still been finding it painfully slow for plshade calls. > > It turned out that almost all the time within the backend (>99%) was > > spent selecting pens and brushes and allocating memory for every > > fill within the plshade call. Less that 1% was actually spent within > > the rendering call to wxWidgets. I have made some good improvements > > here. > > > > However, in addition to this, about 50% of the total execution time > > is spent in the setlocale function. This is called before and after > > each polygon fill in the core plplot code. > > > > I wondered if anyone really knows the purpose of these calls? > > Perhaps they are to ensure we have consistent numeric > > representations across regions? If so, then I don't really > > understand why they are needed for polygon fills. > > > > Any thoughts would be welcome > > Phil > > > > > > > > _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> > > > > On 5/31/23 10:56, Phil Rosenberg wrote: >> Sorry, I was wrong in my last email - removing the locale calls from >> plP_state as well (used to reset the width after a contour draw within >> plshade) I ended up with a 2.5 times speed increase >> >> Phil >> >> On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... >> <mailto:p.d...@gm... <mailto:p.d...@gm...>>> wrote: >> >> Hi all >> I have been making further optimisations to the wxwidgets backen, as >> I have still been finding it painfully slow for plshade calls. >> It turned out that almost all the time within the backend (>99%) was >> spent selecting pens and brushes and allocating memory for every >> fill within the plshade call. Less that 1% was actually spent within >> the rendering call to wxWidgets. I have made some good improvements >> here. >> >> However, in addition to this, about 50% of the total execution time >> is spent in the setlocale function. This is called before and after >> each polygon fill in the core plplot code. >> >> I wondered if anyone really knows the purpose of these calls? >> Perhaps they are to ensure we have consistent numeric >> representations across regions? If so, then I don't really >> understand why they are needed for polygon fills. >> >> Any thoughts would be welcome >> Phil >> >> >> >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> https://list/ <https://list/> >> s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7Carj >> en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed >> 7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb >> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3D%7C3000%7C%7C%7C&sdata=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb >> 7gY%3D&reserved=0 > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> > DISCLAIMER: This message is intended exclusively for the addressee(s) > and may contain confidential and privileged information. If you are not > the intended recipient please notify the sender immediately and destroy > this message. Unauthorized use, disclosure or copying of this message is > strictly prohibited. The foundation 'Stichting Deltares', which has its > seat at Delft, The Netherlands, Commercial Registration Number 41146461, > is not liable in any way whatsoever for consequences and/or damages > resulting from the improper, incomplete and untimely dispatch, receipt > and/or content of this e-mail. > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > <https://lists.sourceforge.net/lists/listinfo/plplot-devel> |
From: Phil R. <p.d...@gm...> - 2023-06-02 09:55:35
|
Hi Hazen, Arjen Thanks for the detective work - Alan has used that feature to help me in the past and I had totally forgotten about it. I can see Alan's intention here. In the wxWidgets driver I did similar things with other properties. For example I ensure the device context pen and brush are always set and reset during calls to the driver. This is so that if the user draws to the device context between calls, then plPlot does not cause problems for the user and visa-versa. Setting and resetting the brush was also an expensive operation, so to avoid those calls I have added an escape for starting and stopping plshade. I know that between these escapes there is no need to worry about setting and restoring the state. I think there are a few options, from most intrusive to least intrusive. 1. Undo Alan's work and make it the responsibility of the driver to restore the locale. This is what wxWidgets does with device context brushes. 2. Find where we think the locale might need saving and restoring and only do it for these calls. I'm not sure I like this, as it makes responsibility a grey area. Also I just tried 'ack locale' and 'ack LC_NUMERIC in the src directory and found references only in plargs.c, plcore.c and plctrl.c. So I don't think any drivers do actually change the locale. 3. I can add a variable to the PLStream which records when we enter and leave a plshade call. This can be checked during plfill calls so that only direct plfill calls save and restore the locale. My preference is for 1 or 3, does anyone else have a preference or other thought? 3 is certainly an easier change, but I'm happy to go down another route if people think it will be an improvement. Just to give an idea of the overall benefits here. I'm plotting data on a grid with millions of points. The wxWidgets driver changes I mentioned above and the removal of the locale save/restore and the changes I mentioned a few weeks ago with buffer memory, mean that instead of giving up after plPlot had been rendering for a few hours, the plot is rendered in under 2 minutes. So that's around two orders of magnitude speed increase at least. Phil ________________________________ From: Arjen Markus <Arj...@de...> Sent: Friday, June 2, 2023 7:47:08 AM To: Hazen Babcock <hba...@ma...>; plp...@li... <plp...@li...> Subject: Re: [Plplot-devel] setlocale Hi Hazen, Phil, If the setting and restoring of the locale takes so much time, then would it be an option to use this only on the plot functions that might actually be affected by the locale? I have only glanced at the code and I have no idea how much work it would be. That would preserve the intended functionality though and get rid of the performance issue. Regards, Arjen -----Original Message----- From: Hazen Babcock via Plplot-devel <plp...@li...> Sent: Thursday, June 1, 2023 12:57 AM To: plp...@li... Subject: Re: [Plplot-devel] setlocale Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment. Github has an interesting feature which lets you browse the code and see the last commit that touched a particular part of the code. Using that it looks like saving and restoring the locale was added to the functions in src/plcore.c by Alan on Sep 7, 2009. The commit message: """ Protect all device driver calls using the (now) reentrant plsave_set_... ...locale and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC locale and then sets the LC_NUMERIC locale to "C" for everything done by all device drivers. Of course, any library called by a device driver can also change the locale, but we guard against such changes affecting the rest of PLplot by using plrestore_locale to restore the fundamental PLplot LC_NUMERIC locale saved by plsave_set_locale. N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except for the parts like the device drivers and palette file reading that are protected by the combination of plsave_set_locale and plrestore_locale) to be any valid locale set by any application or library that calls the PLplot library. If that locale specifies comma decimal separators rather than period decimal separators, for example, then the PLplot core will automatically use those for for specifying axis labels. Those commas for axis labels are drawn by the PLplot core for the Hershey font device drivers or just propagate to the unicode device drivers as UCS4 arrays. Thus, in both cases, we get a comma decimal separator for axis labels (if that is what the fundamental PLplot LC_NUMERIC locale calls for) independently of the logic of the present commit that sets the LC_NUMERIC locale to "C" for all device driver code that is executed. svn path=/trunk/; revision=10383 """ -Hazen On 5/31/23 10:56, Phil Rosenberg wrote: > Sorry, I was wrong in my last email - removing the locale calls from plP_state as well (used to reset the width after a contour draw within plshade) I ended up with a 2.5 times speed increase > > Phil > > On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote: > > Hi all > I have been making further optimisations to the wxwidgets backen, as > I have still been finding it painfully slow for plshade calls. > It turned out that almost all the time within the backend (>99%) was > spent selecting pens and brushes and allocating memory for every > fill within the plshade call. Less that 1% was actually spent within > the rendering call to wxWidgets. I have made some good improvements > here. > > However, in addition to this, about 50% of the total execution time > is spent in the setlocale function. This is called before and after > each polygon fill in the core plplot code. > > I wondered if anyone really knows the purpose of these calls? > Perhaps they are to ensure we have consistent numeric > representations across regions? If so, then I don't really > understand why they are needed for polygon fills. > > Any thoughts would be welcome > Phil > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel On 5/31/23 10:56, Phil Rosenberg wrote: > Sorry, I was wrong in my last email - removing the locale calls from > plP_state as well (used to reset the width after a contour draw within > plshade) I ended up with a 2.5 times speed increase > > Phil > > On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... > <mailto:p.d...@gm...>> wrote: > > Hi all > I have been making further optimisations to the wxwidgets backen, as > I have still been finding it painfully slow for plshade calls. > It turned out that almost all the time within the backend (>99%) was > spent selecting pens and brushes and allocating memory for every > fill within the plshade call. Less that 1% was actually spent within > the rendering call to wxWidgets. I have made some good improvements > here. > > However, in addition to this, about 50% of the total execution time > is spent in the setlocale function. This is called before and after > each polygon fill in the core plplot code. > > I wondered if anyone really knows the purpose of these calls? > Perhaps they are to ensure we have consistent numeric > representations across regions? If so, then I don't really > understand why they are needed for polygon fills. > > Any thoughts would be welcome > Phil > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://list/ > s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7Carj > en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed > 7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7C3000%7C%7C%7C&sdata=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb > 7gY%3D&reserved=0 _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <Arj...@de...> - 2023-06-02 07:21:10
|
Hi Hazen, Phil, If the setting and restoring of the locale takes so much time, then would it be an option to use this only on the plot functions that might actually be affected by the locale? I have only glanced at the code and I have no idea how much work it would be. That would preserve the intended functionality though and get rid of the performance issue. Regards, Arjen -----Original Message----- From: Hazen Babcock via Plplot-devel <plp...@li...> Sent: Thursday, June 1, 2023 12:57 AM To: plp...@li... Subject: Re: [Plplot-devel] setlocale Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment. Github has an interesting feature which lets you browse the code and see the last commit that touched a particular part of the code. Using that it looks like saving and restoring the locale was added to the functions in src/plcore.c by Alan on Sep 7, 2009. The commit message: """ Protect all device driver calls using the (now) reentrant plsave_set_... ...locale and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC locale and then sets the LC_NUMERIC locale to "C" for everything done by all device drivers. Of course, any library called by a device driver can also change the locale, but we guard against such changes affecting the rest of PLplot by using plrestore_locale to restore the fundamental PLplot LC_NUMERIC locale saved by plsave_set_locale. N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except for the parts like the device drivers and palette file reading that are protected by the combination of plsave_set_locale and plrestore_locale) to be any valid locale set by any application or library that calls the PLplot library. If that locale specifies comma decimal separators rather than period decimal separators, for example, then the PLplot core will automatically use those for for specifying axis labels. Those commas for axis labels are drawn by the PLplot core for the Hershey font device drivers or just propagate to the unicode device drivers as UCS4 arrays. Thus, in both cases, we get a comma decimal separator for axis labels (if that is what the fundamental PLplot LC_NUMERIC locale calls for) independently of the logic of the present commit that sets the LC_NUMERIC locale to "C" for all device driver code that is executed. svn path=/trunk/; revision=10383 """ -Hazen On 5/31/23 10:56, Phil Rosenberg wrote: > Sorry, I was wrong in my last email - removing the locale calls from plP_state as well (used to reset the width after a contour draw within plshade) I ended up with a 2.5 times speed increase > > Phil > > On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote: > > Hi all > I have been making further optimisations to the wxwidgets backen, as > I have still been finding it painfully slow for plshade calls. > It turned out that almost all the time within the backend (>99%) was > spent selecting pens and brushes and allocating memory for every > fill within the plshade call. Less that 1% was actually spent within > the rendering call to wxWidgets. I have made some good improvements > here. > > However, in addition to this, about 50% of the total execution time > is spent in the setlocale function. This is called before and after > each polygon fill in the core plplot code. > > I wondered if anyone really knows the purpose of these calls? > Perhaps they are to ensure we have consistent numeric > representations across regions? If so, then I don't really > understand why they are needed for polygon fills. > > Any thoughts would be welcome > Phil > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel On 5/31/23 10:56, Phil Rosenberg wrote: > Sorry, I was wrong in my last email - removing the locale calls from > plP_state as well (used to reset the width after a contour draw within > plshade) I ended up with a 2.5 times speed increase > > Phil > > On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... > <mailto:p.d...@gm...>> wrote: > > Hi all > I have been making further optimisations to the wxwidgets backen, as > I have still been finding it painfully slow for plshade calls. > It turned out that almost all the time within the backend (>99%) was > spent selecting pens and brushes and allocating memory for every > fill within the plshade call. Less that 1% was actually spent within > the rendering call to wxWidgets. I have made some good improvements > here. > > However, in addition to this, about 50% of the total execution time > is spent in the setlocale function. This is called before and after > each polygon fill in the core plplot code. > > I wondered if anyone really knows the purpose of these calls? > Perhaps they are to ensure we have consistent numeric > representations across regions? If so, then I don't really > understand why they are needed for polygon fills. > > Any thoughts would be welcome > Phil > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://list/ > s.sourceforge.net%2Flists%2Flistinfo%2Fplplot-devel&data=05%7C01%7Carj > en.markus%40deltares.nl%7C44980f7a89174ac2fd6a08db622a585a%7C15f3fe0ed > 7124981bc7cfe949af215bb%7C0%7C0%7C638211706231092344%7CUnknown%7CTWFpb > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7C3000%7C%7C%7C&sdata=%2FhX%2F5cUnr67tJIMuLcD1eZgofgKQONlnSgYD4QIb > 7gY%3D&reserved=0 _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Hazen B. <hba...@ma...> - 2023-05-31 22:56:50
|
Github has an interesting feature which lets you browse the code and see the last commit that touched a particular part of the code. Using that it looks like saving and restoring the locale was added to the functions in src/plcore.c by Alan on Sep 7, 2009. The commit message: """ Protect all device driver calls using the (now) reentrant plsave_set_… …locale and plrestore_locale. The former saves the fundamental PLplot LC_NUMERIC locale and then sets the LC_NUMERIC locale to "C" for everything done by all device drivers. Of course, any library called by a device driver can also change the locale, but we guard against such changes affecting the rest of PLplot by using plrestore_locale to restore the fundamental PLplot LC_NUMERIC locale saved by plsave_set_locale. N.B. this logic allows the fundamental PLplot LC_NUMERIC locale (except for the parts like the device drivers and palette file reading that are protected by the combination of plsave_set_locale and plrestore_locale) to be any valid locale set by any application or library that calls the PLplot library. If that locale specifies comma decimal separators rather than period decimal separators, for example, then the PLplot core will automatically use those for for specifying axis labels. Those commas for axis labels are drawn by the PLplot core for the Hershey font device drivers or just propagate to the unicode device drivers as UCS4 arrays. Thus, in both cases, we get a comma decimal separator for axis labels (if that is what the fundamental PLplot LC_NUMERIC locale calls for) independently of the logic of the present commit that sets the LC_NUMERIC locale to "C" for all device driver code that is executed. svn path=/trunk/; revision=10383 """ -Hazen On 5/31/23 10:56, Phil Rosenberg wrote: > Sorry, I was wrong in my last email - removing the locale calls from plP_state as well (used to reset the width after a contour draw within plshade) I ended up with a 2.5 times speed increase > > Phil > > On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote: > > Hi all > I have been making further optimisations to the wxwidgets backen, as > I have still been finding it painfully slow for plshade calls. > It turned out that almost all the time within the backend (>99%) was > spent selecting pens and brushes and allocating memory for every > fill within the plshade call. Less that 1% was actually spent within > the rendering call to wxWidgets. I have made some good improvements > here. > > However, in addition to this, about 50% of the total execution time > is spent in the setlocale function. This is called before and after > each polygon fill in the core plplot code. > > I wondered if anyone really knows the purpose of these calls? > Perhaps they are to ensure we have consistent numeric > representations across regions? If so, then I don't really > understand why they are needed for polygon fills. > > Any thoughts would be welcome > Phil > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel On 5/31/23 10:56, Phil Rosenberg wrote: > Sorry, I was wrong in my last email - removing the locale calls from > plP_state as well (used to reset the width after a contour draw within > plshade) I ended up with a 2.5 times speed increase > > Phil > > On Mon, 29 May 2023 at 00:38, Phil Rosenberg <p.d...@gm... > <mailto:p.d...@gm...>> wrote: > > Hi all > I have been making further optimisations to the wxwidgets backen, as > I have still been finding it painfully slow for plshade calls. > It turned out that almost all the time within the backend (>99%) was > spent selecting pens and brushes and allocating memory for every > fill within the plshade call. Less that 1% was actually spent within > the rendering call to wxWidgets. I have made some good improvements > here. > > However, in addition to this, about 50% of the total execution time > is spent in the setlocale function. This is called before and after > each polygon fill in the core plplot code. > > I wondered if anyone really knows the purpose of these calls? > Perhaps they are to ensure we have consistent numeric > representations across regions? If so, then I don't really > understand why they are needed for polygon fills. > > Any thoughts would be welcome > Phil > > > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |