Acting upon the advice that replacing matrix-matrix multiplications in
vectorized form with loops would help with performance, I chopped out a
piece of code from my finite element solver
(https://gist.github.com/anonymous/4ec426096c02faa4354d) and ran some tests
with the following results:
See the comment in the gist.
2014-12-11 11:47 GMT-05:00 Petr Krysl krysl.p...@gmail.com:
Acting upon the advice that replacing matrix-matrix multiplications in
vectorized form with loops would help with performance, I chopped out a
piece of code from my finite element solver (
Dear Andreas,
Thank you very much. True, I have not noticed that. I put the definitions
of the arrays outside of the two functions so that their results could be
compared.
What I'm trying to do here is write a simple chunk of code that would
reproduce the conditions in the FE package.
There
One more note: I conjectured that perhaps the compiler was not able to
infer correctly the type of the matrices, so I hardwired (in the actual FE
code)
Jac = 1.0; gradN = gradNparams[j]/(J); # get rid of Rm for the moment
About 10% less memory used, runtime about the same. So, no effect
One thing I noticed after a quick glance: The ordering of your nested
loops is very cache-unfriendly. Julia stores arrays in column-major order
(same as Fortran) so that nested loops should arrange that the first
subscripts of multidimensional arrays are varied most rapidly.
--Peter
On
I experimented with it a little bit before (mx innermost loop): does not
make a difference.
On Thursday, December 11, 2014 9:55:46 AM UTC-8, Peter Simon wrote:
One thing I noticed after a quick glance: The ordering of your nested
loops is very cache-unfriendly. Julia stores arrays in
Right. looking into it...
How do you stop a task preemptively in Julia's built-in framework?
On Friday, October 24, 2014 8:07:19 AM UTC+7, Steven G. Johnson wrote:
On Thursday, October 23, 2014 9:13:06 AM UTC-4, Tony Fong wrote:
I also have a similar need. If I want to be more fancy, what
Answering my own question, there seems there's a function throwto( task,
exc )
On Friday, October 24, 2014 2:40:20 PM UTC+7, Tony Fong wrote:
Right. looking into it...
How do you stop a task preemptively in Julia's built-in framework?
On Friday, October 24, 2014 8:07:19 AM UTC+7, Steven
I also have a similar need. If I want to be more fancy, what may be the
strategy to address the following 2-way communication?
* UI - worker: send pause, abort
* worker - UI: progress report, summary state (presumably to allow UI to
do fancier presentation)
I'm thinking about looking into
On Thursday, October 23, 2014 9:13:06 AM UTC-4, Tony Fong wrote:
I also have a similar need. If I want to be more fancy, what may be the
strategy to address the following 2-way communication?
* UI - worker: send pause, abort
* worker - UI: progress report, summary state (presumably to
I've started trying to write code that would allow me to take an existing
while-loop or for-loop and augment it with the ability for a user to pause the
computation and terminate it early. This is really useful in Optim, where you
might want to stop optimizing as soon as the solution hits a
Note too that instead of readavailable, it seems like you want read(io,
Uint8)
As an extension of Steven's suggestion, you could use other signals too (eg
like how 'kill -SIGINFO' will give you a backtrace)
On Wednesday, October 22, 2014, Steven G. Johnson stevenj@gmail.com
wrote:
Couldn't
well, yes. on linux, “run(`kill -SIGUSR1 $(getpid())`)” is the way to get
the instant backtrace
window’s unfortunately has a limited number of signals available (SHUTDOWN,
LOGOFF, SIGKILL, SIGINT, and ctrl-break) which aren’t terribly helpful for
this
and just for fun, there’s an alternative
This is great work, thanks Valentin!
On Tuesday, August 5, 2014 11:48:19 AM UTC-5, Valentin Churavy wrote:
I mean you could skip the map and use a reduce directly thus skipping the
array allocation.
You could skip the array allocation by using reduce instead of the
map()... construct
And *another* correction: the proper replacement for the promote_type loop
is
T = promote_type(map(typeof,X)...)
Note the eliipsis. I apologize for the rapid-fire posts.
Stefan,
Thank you. Your description really helps clarify things. The issue about
different functionality for return in map vs for loops was obviously
something I overlooked here.
And yes, the influence is clearly ruby.
I see how a macro could can duplicate the for loop structure. I guess I'm a
That form of iteration is common from Ruby, which is where I'm guessing
this interest is coming from? Ruby has the block/proc/lambda distinction
that makes the for loop and .each forms behaviorally similar, whereas in
Julia, there's just the one kind of anonymous function. As a result, if
this
I love the
for file in files
... do something with file ...
end
syntax. But sometimes it's really useful to be able to have an iterator
accessible in the for loop, like:
for file in files
... do something with file ...
... and with i that equals find(file == files) ...
end
Is there something
What about enumerate:
http://docs.julialang.org/en/latest/stdlib/base/?highlight=enumerate#Base.enumerate?
On Thu, May 15, 2014 at 2:48 PM, Yakir Gagnon 12.ya...@gmail.com wrote:
I love the
for file in files
... do something with file ...
end
syntax. But sometimes it's really useful to be
I was thinking the same thing the other day, when using *for x in xs* I
often find myself needing an index at some point and then I have to change
the for loop, or write an index manually.
Enumerate is exactly what I need in this case.
+1 for Julia
One nice thing about Julia is that she borrows many (though not all) good
ideas from other languages. In this case, enumerate came from Python
(although it likely has other incarnations).
Cheers!
Kevin
On Thursday, May 15, 2014, Billou Bielour jonathan.bie...@epfl.ch wrote:
I was thinking
You may also be interested in zip:
for (file, i) in zip(files, 1:length(files))
println(file, , i)
end
# Even better:
using Lazy
for (file, i) in zip(files, range())
println(file, , i)
end
Enumerate is definitely the best solution here, but zip is more general if
you find yourself
OMG. So awesome! Thanks!!!
Yakir Gagnon
The Queensland Brain Institute (Building #79)
The University of Queensland
Brisbane QLD 4072
Australia
cell +61 (0)424 393 332
work +61 (0)733 654 089
On Thu, May 15, 2014 at 11:33 PM, Kevin Squire kevin.squ...@gmail.comwrote:
One nice thing about
Love the Lazy thing, I'm real tempted to use lazy more, will do once I'm
more sure of what I'm doing.
Yakir Gagnon
The Queensland Brain Institute (Building #79)
The University of Queensland
Brisbane QLD 4072
Australia
cell +61 (0)424 393 332
work +61 (0)733 654 089
On Thu, May 15, 2014 at
I kind of suspect Stefan, like me, would instinctively call this operation
`each_with_index`.
-- John
On May 15, 2014, at 6:33 AM, Kevin Squire kevin.squ...@gmail.com wrote:
One nice thing about Julia is that she borrows many (though not all) good
ideas from other languages. In this case,
I missed enumerate() for a while, and was happy I found it. I find it
amusing how satisfying a few missing keystrokes can be.
On a related but different note, from a similar influence, I keep wanting
to pass blocks to iterators. Any chance that will ever happen?
I realize that do..end blocks
Well, if you want the first syntax you can easily define
Base.enumerate(f::Function, args...) = map(t-f(t...), enumerate(args...))
You could always open a pull request if you wanted to see this in Base, too.
On Thursday, 15 May 2014 21:18:31 UTC+1, Cameron McBride wrote:
I missed enumerate()
Sure, Mike. But the idea is to have this for all iterator objects
intrinsically rather than defining it for each function that returns an
iterator.
There is likely a way to do this automagically for all iterators, but my
julia-fu isn't strong enough that it jumped out at me when I looked over
Ah, I see what you mean. I'm not sure if it's possible, though.
You'd have to determine whether f() do ... meant function with do block
or iterator with do block, which isn't possible in general. So at least
you'd need special syntax for it, and by that point it's probably easier to
stick with
29 matches
Mail list logo
