Hans, it would be interesting to see how your Pollard Rho example compares
on the pooling bigint branch https://github.com/JuliaLang/julia/pull/10084.
It ought to allocate far less memory...
On 20 March 2015 at 00:01, Hans W Borchers hwborch...@gmail.com wrote:
As Bill noted, it is known that
As Bill noted, it is known that Pollard Rho does not perform comparably
for
all numbers of the same size. Still I got interested in trying it out
myself.
I wrote a simple implementation and got this result:
julia n = big(3)^100 + 2
julia @time factorize(n)
elapsed time:
Den fredag 20 mars 2015 kl. 05:36:15 UTC+1 skrev Kiran Pamnany:
Hey Stefan,
Depending on how well Julia-generated code performs, some important
concurrent data structures might be better implemented in C and wrapped.
I would argue that until we can implement efficient concurrent data
If you are interested in some relatively serious number theory with Julia,
there is the Nemo library we are writing in Julia.
https://github.com/wbhart/Nemo.jl
Unfortunately it is between versions at the moment (see the rewrite branch,
and not everything is even pushed to that). We simply call
I reported the same issue here:
https://github.com/JuliaLang/julia/issues/9145
Am Donnerstag, 19. März 2015 20:45:48 UTC+1 schrieb Wen Ling:
thanks for the info
On Thursday, March 19, 2015 at 2:10:25 PM UTC-4, Tony Kelman wrote:
Looks like osxunwind has some inline assembly that the intel
I really appreciate the fact that I can input an integer with underscores,
as in
a = 1_000_000
Would it be a silly suggestion to also print integers with underscores? I
sometimes find myself counting digits to interpret an output
output = 1102160376
Or is there a simple way for me to
Also, don't forget that there's a big difference between *being able to*
use something like pragmas to squeeze out performance, and *having to*.
We're already exposing some stuff that potentially make things way faster
if you can promise stuff that the compiler can't, e.g. @inbounds. @aligned
Le vendredi 20 mars 2015 à 14:03 -0700, Julia User a écrit :
I looked through some of the Base source code and see different things
for conversions.
c%UInt8
convert(UInt8,x)
UInt8(t)
to name a few
Any official recommendation for someone starting out new - anything
which is
Hello,
I'm a new user trying to run Julia under the Juno IDE.
My environment is Windows 8.1 (x64) and Microsoft SQL Server 2014.
On the SQL Server side, I setup the ODBC driver as follows.
https://lh5.googleusercontent.com/-ZNJawNMaC9Y/VQy0KtmKgXI/ACI/2Lv8RNgyHhY/s1600/Setup%2Bodbc.png
You might try using the `ODBC.advancedconnect()` function. It will
typically pop up with a window to put the info in.
On Fri, Mar 20, 2015 at 6:13 PM, Charles Brauer charlesbra...@gmail.com
wrote:
Hello,
I'm a new user trying to run Julia under the Juno IDE.
My environment is Windows 8.1
I looked through some of the Base source code and see different things for
conversions.
c%UInt8 https://github.com/JuliaLang/julia/blob/master/base/utf8.jl#L125
convert(UInt8,x)
https://github.com/JuliaLang/julia/blob/master/base/int.jl#L224
UInt8(t)
0.3.7 today ?
On Wednesday, February 18, 2015 at 8:41:01 AM UTC+1, Elliot Saba wrote:
Hello all! The latest bugfix release of the 0.3.x Julia line has been
released. Binaries are available from the usual place
http://julialang.org/downloads/, and as is typical with such things,
please
Humanize.jl also works nicely for this, e.g.
digitsep(12345678, sep = _)
https://github.com/IainNZ/Humanize.jl
On Friday, March 20, 2015 at 5:54:11 PM UTC+1, Peter Simon wrote:
Also, perhaps you would be interested in the Formatting package:
julia using Formatting
julia
You could insert this line:
a[a .==0] = 0.1
to tweak the zero values so that they plot...
Yes, not an elegant solution!
I am not sure if this would go through as a PR, but you would have to look
in base/intfuncs.jl for the function signature:
function dec(x::Unsigned, pad::Int, neg::Bool)
This generates the decimal representation for Integers. If you checked out
and compiled Julia yourself you can simply
This, to me, sounds like the beginning of a rabbit-hole, which leads to the
same morass of architecture-specific directives that infect many codes,
particularly in HPC where codes can live a long time. I think it'd be
better to tuck this mess away under the hood.
Turning off bounds-checking
One thing I've noted while monitoring the CPU usage of my processes: it
appears that the main process isn't doing any work at all, i.e. three
processes are running at 12.5% CPU, while the main process sits at 0% most
of the time. Is this expected behaviour for the @parallel macro?
I'm still having problems understanding the basic concepts of
parallelization in Julia. It seems to me that the examples in the
documentation and those that I found elsewhere on the web don't really
reflect my usage case, so I'm wondering whether I'm approaching the problem
from the right
Try making the grids formal arguments to solveall():
function solveall(agrid, bgrid, cgrid, dgrid)
...
end
@time solveall(agrid, bgrid, cgrid, dgrid)
Then you should be able to switch the loop you're parallelizing over.
You probably also need a @sync somewhere to ensure all the workers are
You mean turning all arrays into SharedArrays, rather than just the result
array?
My understanding was that SharedArrays are only needed if the remote
processes have to write on them, while regular Arrays are the way to go if
the functions called on the remote processes simply read from them.
Thanks, that's a great suggestion! Writing:
function solveall(agrid, bgrid, cgrid, dgrid)
@sync @parallel for a = 1:length(agrid)
...
end
return result
end
@time solveall(agrid, bgrid, cgrid, dgrid)
Reduces the time to ~4.3s, just about half the time of the single core
On Friday, March 20, 2015 at 11:48:40 AM UTC-5, Nils Gudat wrote:
Thanks, that's a great suggestion! Writing:
function solveall(agrid, bgrid, cgrid, dgrid)
@sync @parallel for a = 1:length(agrid)
...
end
return result
end
@time solveall(agrid, bgrid, cgrid, dgrid)
Reduces
I posted an issue
https://github.com/JuliaParallel/DistributedArrays.jl/issues/7 on the
DArrays repo but someone in IRC suggested opening a thread here as well.
I'm seeing different results from map vs pmap on a DArray in Julia
0.4.0-dev+3844 on Linux. When I run, on 6 procs:
julia testa =
There have been fewer backports over the past month. It would help if
people can go through and flag any bug fixes or documentation updates that
would also apply to the release-0.3 branch. Either mention the
@juliabackports user in a commit comment, or add the Backport pending
label to a
I agree that one doesn't want to expose all of what C + pragmas + inline
assembly can do at the higher level, but I suspect there's some set of
functionality that can let you do most of the work at the higher level. But
we'll see how it pans out. Maybe the high-level functionality is a set of
data
Thanks for the reminder Helge. So there is already an open issue on it.
If you would like to try fixing this, the source for osxunwind is
at https://github.com/JuliaLang/libosxunwind
There might be a newer upstream release of that library from Apple that we
could use to rebase any local changes
26 matches
Mail list logo
