bugGNU Octave - Bugs: bug #35400, Performance of in-place operations

 
 

bug #35400: Performance of in-place operations

Submitted by:  Rik <rik5>
Submitted on:  Mon Jan 30 01:45:07 2012  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Performance
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun Nov 20 14:50:16 2016, comment #3:

This certainly could be fixed, but it will require medium to major changes to how the parser works. This isn't necessarily a bad thing. There is a subsasgn bug already out which would require the same change. There have been requests to recognized true uint64 bit constants which the parser currently converts to double, etc.

Rik <rik5>
Project Administrator
Sat Nov 19 20:10:48 2016, comment #2:

This issue is still (partly) present in Octave 4.2.0.

I now get the following result from the test script:

So we somehow improved the performance of the second command to match the third one. But the first one is still slower by a factor of two.

Would it be feasible at all, to perform the first (and most general syntax) command "x = x + 1" as an in place accumulation at all? If "no", then let's close this issue. If "yes", then let's keep it open.

Hartmut <hardy>
Mon Jan 27 02:29:54 2014, comment #1:

I get roughly the same results, still an issue in the current development version.

Mike Miller <mtmiller>
Project Administrator
Mon Jan 30 01:45:07 2012, original submission:

The increment operation can be coded a number of different ways in Octave.

After benchmarking the operations, it turns out that the third form is significantly faster (> 2X) than the others. It is disconcerting to have the performance depend so heavily on exactly what construct the coder uses.

The reason for the performance speed-up is the work done by Jaroslav which means that the third case uses in-place accumulation rather than assigning to a temporary array.

One possible solution would be to have the parser recognize the first two forms as in-place operations and map to the existing code used in the third form. This issue applies to any of the operators which also have in-place forms (+=, -=, *=, /=, &=, |=, ^=, etc.)

I'm attaching a benchmark script I used (bm_accum.m). The test results are:

x = x + 1;
Elapsed time is 1.7 seconds.
x++;
Elapsed time is 1.8 seconds.
x += 1;
Elapsed time is 0.69 seconds.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #24912:  bm_accum.m added by rik5 (147B - text/x-octave)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by hardy (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Jan 27 02:29:54 2014mtmillerStatusNone=>Confirmed
      Release3.6.0=>dev
    Mon Jan 30 01:45:07 2012rik5Attached File-=>Added bm_accum.m, #24912

    Back to the top


    Powered by Savane 3.1-cleanup