bugGNU Octave - Bugs: bug #64882, Slow to pass arrays out of...

 
 

bug #64882: Slow to pass arrays out of mexFunction

Submitter:  None
Submitted:  Sat 11 Nov 2023 01:59:17 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 8.3.0
Release:  Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 28 Dec 2023 04:28:10 PM UTC, comment #13: 

Given that there is a simple workaround (upgrading the compiler), I don't think we want to use limited developer resources on porting a different polymorphic allocator, such as that from Boost, into Octave's code base and distributing it.

The original reporter has their issue resolved so I am going to close this report.

Rik <rik5>
Group administrator
Thu 28 Dec 2023 01:36:12 PM UTC, comment #12: 

See bug #65034 for a patch that would switch the default for polymorphic allocators from disable to enable (if possible).

Markus Mützel <mmuetzel>
Group administrator
Thu 28 Dec 2023 12:40:38 PM UTC, comment #11: 

Oops. Once the holidays are over, it feels like the year has ended. But to be clear: LLVM 16 was released in April 2023 (so technically still this year).

Markus Mützel <mmuetzel>
Group administrator
Thu 28 Dec 2023 12:38:23 PM UTC, comment #10: 

GCC 7 already supported most of C++17. But you are right that support for polymorphic memory resources was introduced with GCC 9.
Clang added support for polymorphic memory resources in LLVM 16 (released last year).
And some (exotic?) compilers still don't support it (e.g., the IBM C++ compiler [1]). So, I wouldn't go so far to require C++17 (and in particular, support for polymorphic memory resources). However, defaulting it to enable polymorphic allocators if possible would probably be fine.

[1]: https://en.cppreference.com/w/cpp/compiler_support/17#C.2B.2B17_library_features

Markus Mützel <mmuetzel>
Group administrator
Thu 28 Dec 2023 04:42:11 AM UTC, comment #9: 

As a developer, I'm fine moving up to C++17.  gcc 9.1 was the first to support C++17 and that version was released May 3, 2019 so almost 5 years ago.  For anyone really concerned about performance, they should be updating their hardware and software more frequently than that.

Rik <rik5>
Group administrator
Thu 28 Dec 2023 02:54:27 AM UTC, comment #8: 
Anonymous
Thu 28 Dec 2023 02:33:25 AM UTC, comment #7: 

I don't think there is an easy/good way to get the speed improvement and properly fix bug #61472.  We already did the work to use the C++ polymorphic allocator.  Using another technique now means more work and worse code (IMHO).

John W. Eaton <jwe>
Group administrator
Thu 28 Dec 2023 01:22:53 AM UTC, comment #6: 

@Markus: Is there any way to get this improvement for users not running C++17?

Rik <rik5>
Group administrator
Mon 13 Nov 2023 09:21:17 PM UTC, comment #5: 

Correction, g++-9. That solved it!

octave:4> A=rand(20000);
octave:5> tic;B=TestFunc(A);toc
Entered      : Elapsed time is 0.00041604 seconds.
Parsed args  : Elapsed time is 0.000488043 seconds.
Created array: Elapsed time is 1.83954 seconds.
Elapsed time is 1.83962 seconds.

Well, apart from the 1.8 seconds to calloc a 3Gb array... ;)

Anonymous
Mon 13 Nov 2023 08:55:23 PM UTC, comment #4: 

Nice catch. I did a quick scan and saw this:

configure:14917: checking whether std::pmr::polymorphic_allocator is available
configure:14968: g++ -std=gnu++17 -c -g -O2  conftest.cpp >&5
conftest.cpp:71:16: fatal error: memory_resource: No such file or directory
       #include <memory_resource>
                ^~~~~~~~~~~~~~~~~
compilation terminated.
configure:14968: $? = 1
configure: failed program was:
| /* confdefs.h */

Trying again with g++-8.

Anonymous
Mon 13 Nov 2023 07:48:23 AM UTC, comment #3: 

Could you please upload the config.log file? (To make sure it actually used std::pmr::polymorphic_allocator. And potentially find why it might not have used it.)

Markus Mützel <mmuetzel>
Group administrator
Sun 12 Nov 2023 07:55:20 PM UTC, comment #2: 

Thanks for the suggestion. Tried it - no difference.

octave:7> A=rand(20000);
octave:8> tic;B=TestFunc(A);toc
Entered      : Elapsed time is 0.000444889 seconds.
Parsed args  : Elapsed time is 0.000519991 seconds.
Created array: Elapsed time is 1.85883 seconds.
Elapsed time is 4.4488 seconds.

Anonymous
Sun 12 Nov 2023 09:42:07 AM UTC, comment #1: 

Could you try to configure Octave with `--enable-std-pmr-polymorphic-allocator`? Does that make a difference? (You'll need a compiler that supports C++17 to be able to build with that configuration.)

Markus Mützel <mmuetzel>
Group administrator
Sat 11 Nov 2023 01:59:17 PM UTC, original submission:  

Passing a large array out of a mexFunction seems to take an extremely long time. I couldn't get very far figuring out what is happening but it may be related to "mutable" and making deep copies of mxArray types into native Octave types. It's strange because passing large (Octave type) array into a mexFunction doesn't incur the same penalty.

I wonder if this could be improved, even just for a few standard types (numeric arrays).

Attached is a small example which receives a large array and returns a large array of the same size.

>> mex TestFunc.cpp
>> A=rand(20000);
>> tic;B=TestFunc(A);toc


In Octave:
Entered      : Elapsed time is 0.000358105 seconds.
Parsed args  : Elapsed time is 0.000403166 seconds.
Created array: Elapsed time is 1.82221 seconds.
Elapsed time is 4.34962 seconds.

In Matlab:
Entered      : Elapsed time is 0.002034 seconds.
Parsed args  : Elapsed time is 0.002162 seconds.
Created array: Elapsed time is 0.002450 seconds.
Elapsed time is 0.002602 seconds.


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55318:  TestFunc.cpp added by None (651B - text/x-c++src)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-28 rik5 CategoryNone Interpreter
        Item GroupNone Performance
        StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2023-11-13 mmuetzel StatusNone Need Info
    2023-11-11 None Attached File- Added TestFunc.cpp, #55318

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code