help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why is octave 4.2.0 x86_64-w64-mingw32 so slow?


From: Doug Stewart
Subject: Re: why is octave 4.2.0 x86_64-w64-mingw32 so slow?
Date: Mon, 23 Oct 2017 21:23:15 -0400



On Mon, Oct 23, 2017 at 9:11 PM, Ray Tayek <address@hidden> wrote:
On 10/23/2017 4:31 PM, Nicholas Jankowski wrote:


...
Absent trusting us to debug you know far better 5han we do, have you tried using the code profiler? It's not as thorough as matlab's, but it can give you a good idea of what is chewing up your time, which functions are called the most, etc.


i did a profile (please see below). but nothing jumps out at me unless log is real slow.

i would think that one of the cores/threads would be saturated.

thanks



>> profshow
   #  Function Attr     Time (s)   Time (%)        Calls
--------------------------------------------------------
  47       log           310.235      24.39        37282
  28       exp           299.600      23.55        74565
   1     train           172.548      13.56            1
  32    repmat           133.316      10.48       149128
  30     fprop           115.611       9.09        37282
  21  binary *            58.261       4.58       819795
  23  binary +            40.484       3.18       670631
  45 binary ./            39.241       3.08       260814
  48 binary .*            25.855       2.03       298032
  18  binary -            22.245       1.75       484284
  46       sum            13.330       1.05       186346
  50    fflush             7.749       0.61        37315
  31 postfix '             7.535       0.59        37282
  27  prefix -             4.467       0.35        74565
  37       max             4.209       0.33       186410
  29   fprintf             3.656       0.29        37707
  35       all             2.251       0.18       447384
  22   reshape             1.546       0.12       372822
  13      size             1.535       0.12       410139
  44      ones             1.265       0.10       298256

>>

-- 



I think that you don't understand how the os handles the cores and the load.
With a single thread program running full out the os usually farms the load out between all the cores. thus 1 core at 100% 
when it is shared will show up as 4 cores at 25%. I think this is what you are seeing.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]