We are seeing a performance regression with a factor of 1.5 or 2.0
(depending on machine) for the following simple C interface code between
0.4.2 and today's master (not sure where the problem initially showed up,
but within the last 50 days):
import Base: +
typealias ZZ Array{UInt, 1}
functi
I can only partially bisect.
The regression happens between:
75fc9104ee24 (more recent)
and
dc6b0de80550 (older)
But few of the intervening commits actually build, so I can't refine it
further. There's something like 40 commits in that range.
Bill.
On 16 March 2016 at 18:28, Kristoffer Carls
It's actually a regression of more than a factor of 2 on the machine I'm
using.
I'll try to further refine the commit range by hand today.
Bill.
On Wednesday, 16 March 2016 20:45:00 UTC+1, Bill Hart wrote:
>
> I can only partially bisect.
>
> The regression happens between:
>
> 75fc9104ee24 (mo
>
>
> >> The generational part of the GC is a little messy. This is mainly
> >> because the new GC was designed to be an incremental GC and then
> >> gradually transformed into a generational GC... (they are
> >> suprisingly similar).
> >>
> >
> > Oh I didn't even realise that LOL. I
On 15 March 2016 at 20:24, Yichao Yu wrote:
> > I wonder what the issue was, and whether the person who fixed it even
> realised they had fixed it. :-)
>
> There were many GC related PRs. Some of them are for mem-leak. I don't
> remember any one in particular about malloc though
>
> > Actuall
>
>
> > I see. That is a relief. We'll stick with & for now.
> >
> >> more than 2 collection*
> >
> >
> > I see, so collections can happen at any time, not when some block of
> memory
> > is "full".
>
> Yes, it happens whenever the GC thinks there are enough allocation
> since the last time.
>
So
Good to hear the problem seems to be fixed in recent 0.5. Thanks for
checking this.
That gives me more motivation for fixing our code so it can run on the
latest 0.5. Hopefully I can find a way.
I wonder what the issue was, and whether the person who fixed it even
realised they had fixed it. :-)
On 15 March 2016 at 19:45, Bill Hart wrote:
>
>> >
>> > I noticed in the code that it looks like things get promoted if they
>> survive
>> > more than 2 generations (currently). But what happens to the objects
>> between
>>
>> more than 2 collection*
>>
>
> I see, so collections can happen at any
On 15 March 2016 at 19:33, Yichao Yu wrote:
> On Tue, Mar 15, 2016 at 2:18 PM, 'Bill Hart' via julia-users
> wrote:
> >
> > Thanks for your answers. Please see my followup questions below.
> >
> > On 15 March 2016 at 18:45, Yichao Yu wrote:
> >>
On Tuesday, 15 March 2016 19:02:41 UTC+1, Yichao Yu wrote:
>
> On Tue, Mar 15, 2016 at 1:45 PM, Yichao Yu >
> wrote:
> >
> > On Mar 15, 2016 11:56 AM, "'Bill Hart' via julia-users"
> > > wrote:
> >>
> >> We have been
Thanks for your answers. Please see my followup questions below.
On 15 March 2016 at 18:45, Yichao Yu wrote:
>
> On Mar 15, 2016 11:56 AM, "'Bill Hart' via julia-users" <
> julia-users@googlegroups.com> wrote:
> >
> > We have been trying to underst
Yes, s+=i just calls the + function for bignums, which indeed creates a new
BigNum object each iteration.
[It would incidentally be great if we could overload += directly in Julia!!
I wouldn't mind if it was required to return an immutable object because I
could still return a new immutable object
Just to clarify what I meant by "Julia can't be responsible for" I was
talking about the fact that the garbage collector does a gc_collect every
23mb on my machine. If memory is allocated on the C side without calling
jl_gc_counted_malloc to do so, Julia can't be expected to include these
a
Here is the (very primitive) example using mpn's that I mentioned.
import Base: +
typealias ZZ Array{UInt, 1}
function +(a::ZZ, b::Int)
r = ZZ(length(a))
ccall((:__gmpn_add_1, :libgmp), Void, (Ptr{UInt}, Ptr{UInt}, Int, Int),
r, a, 3, b)
return r
end
function doit(n::Int)
a = ZZ(3)
On 15 March 2016 at 17:04, Yichao Yu wrote:
>
> On Mar 15, 2016 11:56 AM, "'Bill Hart' via julia-users" <
> julia-users@googlegroups.com> wrote:
> >
> > We have been trying to understand the garbage collector behaviour, since
> we had some code f
We have been trying to understand the garbage collector behaviour, since we
had some code for which our machine is running out of memory in a matter of
an hour.
We already realised that Julia isn't responsible for memory we allocate on
the C side unless we use jl_gc_counted_malloc, which we now
Thanks. I appreciate the reply.
On 26 February 2016 at 09:32, Mauro wrote:
> > However, could you please explain to me what is involved in updating
> dict?
> > I understand an ObjectIdDict is a hash table whose keys are object ID's.
> > But the documentation doesn't tell me how to generate such
Thanks. Indeed I missed this in the docs, so no ticket needs to be opened.
The fact that overloading deecopy_internal is fully supported is perfectly
fine.
However, could you please explain to me what is involved in updating dict?
I understand an ObjectIdDict is a hash table whose keys are object
On Tuesday, 23 February 2016 15:40:50 UTC+1, Yichao Yu wrote:
>
>
>
> On Tue, Feb 23, 2016 at 9:26 AM, 'Bill Hart' via julia-users <
> julia...@googlegroups.com > wrote:
>
>> We just had a failure of Nemo.jl on Travis on OSX which looks completely
>
Just correcting a typo in my question (the question still stands):
deepcopy(A)[1] == x
was not meant to be written twice. I accidentally copy and pasted it from
my terminal twice.
On Tuesday, 23 February 2016 15:16:08 UTC+1, Bill Hart wrote:
>
> In Nemo.jl we require some objects to be singleto
We just had a failure of Nemo.jl on Travis on OSX which looks completely
random. We replace uint with UInt in two places. Before the patch all
passes. After the patch, segfault on OSX in a fairly unrelated function.
The failure almost seems to random to even bother posting, but here is the
line
In Nemo.jl we require some objects to be singleton. In other words they
should never be deep copied since we require only one of them to exist.
This is causing a problem with deepcopy of arrays that somewhere contain
these objects.
E.g. in Nemo.jl:
Qx,x = PolynomialRing(QQ, "x") # here x conta
One mystery is solved. Elliot Saba pointed out that I was issuing the wrong
command to look for symbols in libjulia.so. And in fact libjulia.so is
expected to be in the "odd" location that I reported, on Ubuntu.
And linking against it does in fact work.
So that leaves one remaining issue, namely
On 9 December 2015 at 04:47, Tony Kelman wrote:
> I'd think a simple shell script, install-julia.sh or something, would be
> better than a Makefile - you don't always have build-essential installed.
> Putting something in contrib (along with a corresponding uninstall-julia.sh
> script?) and addin
I should add that it would still be useful if there was a Makefile to
install Julia system wide after extracting the tarball.
Bill.
On 9 December 2015 at 03:28, Bill Hart wrote:
>
>
> On 9 December 2015 at 01:54, Tony Kelman wrote:
>
>> The PPA is maintained by staticfloat, aka Elliot Saba. He
On 9 December 2015 at 01:54, Tony Kelman wrote:
> The PPA is maintained by staticfloat, aka Elliot Saba. He's had very
> little time for Julia lately and no one has stepped up to take over the PPA
> maintenance from him.
>
Thanks for letting me know. I'll circulate that and see if anyone locally
By the way, I haven't used the generic Linux binaries because I couldn't
figure out how to install them. There's no Makefile and no instructions.
The last time I tried they didn't work when just placed in my home
directory. They seem to need installation somewhere.
I'm pretty sure our Ubuntu users
I've searched my machine and really haven't found libjulia.so, except the
copy I mentioned, which has no symbols.
The PPA's seemed to be very up-to-date with v0.4.1 being available the day
it was released. They also work just fine. I think they are just missing
something.
Where would I even repor
@Kristoffer That's because you have libjulia.so installed on your system.
I've only installed Julia using an Ubuntu ppa, which is missing libjulia.so
apparently.
It obviously looks in the standard system library location for the
libraries it needs (as it should).
The problem here is that we canno
I should add that one thing that number theorists are very interested in is
quaternion algebras, especially over number fields. I hope that will
eventually be done well in Nemo.
Bill.
On 5 December 2015 at 01:42, Bill Hart wrote:
>
>
> On 5 December 2015 at 01:27, Eric Forgy wrote:
>
>> Numero
On 5 December 2015 at 01:27, Eric Forgy wrote:
> Numerous benchmarks have been added to our benchmarks page to show that
>> these implementations are competitive with other systems.
>
>
> Looking at the numbers, I call this an understatement :)
>
Yes, but we are cheating by using the Julia progr
Hi all,
It is with great pleasure that we release Nemo-0.4.
Nemo is a computer algebra package written in the Julia programming
language, with the eventual aim of covering commutative algebra, number
theory and group theory.
For instructions on getting and using Nemo-0.4, including full
document
It would be better with Pollard Rho to list the times depending on the
smallest factor.
It would be interesting to compare timings for some known numbers such as
Fermat numbers (F_n = 2^(2^n) + 1).
Here are some timings from a Google summer of code project we had this year:
F_6 (1844674407370955
Do you mean you are factoring something other than random numbers, or do
you mean your Pollard Rho is completely deterministic?
It's not a good measure of performance to time just one factorisation with
Pollard Rho, since you could just pick the parameters such that it
essentially succeeds immedia
Thanks, I wasn't aware of it. I'll see to it that something gets posted
there.
Bill.
On 29 October 2015 at 14:09, Yichao Yu wrote:
> On Thu, Oct 29, 2015 at 9:06 AM, Bill Hart
> wrote:
> > Hi all,
> >
> > If anyone would be interested in writing an x86_64 assembly
> superoptimiser
> > in Julia
I managed to finally figure out how to use withenv with two arguments (the
first has to be a lambda or function with no parameters).
But the documentation here:
http://julia.readthedocs.org/en/latest/stdlib/base/#Base.withenv
indicates that withenv can also be used with a do..end block. Howev
I think I figured it out, actually. I can set rpath to both possibilities.
One will be silently ignored.
Now if only the rpath wasn't hard coded into the build scripts...
Anyway, this is clearly not a Julia issue. Sorry for the noise.
Bill.
On 9 October 2015 at 22:17, Bill Hart wrote:
> A sy
A system administrator is trying to install our Nemo package system wide on
a VM for his users.
He's located a ticket [1] which gave him the hint to put Nemo into ../
share/julia/site/v0.4 relative to the Julia binary, after Nemo has built
its dependencies.
The problem is, a few of Nemo's depende
Is there any relationship between Julia's lexical scoping and garbage
collection?
What I mean is: if I have a function inside which is a variable which is
not used from some point onwards in the function, does the object live on
until the end of scope or is it possible that it may be gc'd before t
I've just tagged Nemo-0.3.1. This fixes some issues on OSX and on 32 bit
platforms that were reported. Other platforms are not affected.
Note that on OSX we don't provide binaries, but build from source. So you
need a working build environment (a fairly recent Xcode -- is that the
right incantatio
I had a look at Homebrew, but I'm afraid it's quite beyond me. I'm going to
have to wait until our OSX usership has increased enough for someone to
build all the necessary recipes for us.
The homebrew-science tap definitely won't have Antic, since that's brand
new, and we also added quite a lot of
Hi all,
It is with pleasure that we release Nemo, a new computer algebra package
we've been working on that uses the Julia programming language.
The official announcement was made yesterday at the computer algebra
minisymposium at the annual meeting of the German Mathematical Society
(DMV) in Ham
>> module HiThere
>> const AConstant = compute_anything()
>> function AFunction()
>> ccall((:a_cfunction, AConstant), Void, ())
>> end
>> end
>>
>> On Fri, Sep 18, 2015 at 5:10 PM 'Bill Hart' via julia-users <
>> julia-use
question.
>>
>> Bill.
>>
>> On 18 September 2015 at 22:24, Jameson Nash wrote:
>>
>>> That seems like an odd way to write replace(somdir, "\\", ""), but
>>> no, those functions aren't const. You need to actually ca
unctions aren't const. You need to actually call them at compile
> time and store the result in a global const variable.
>
>
> On Fri, Sep 18, 2015 at 2:59 PM 'Bill Hart' via julia-users <
> julia-users@googlegroups.com> wrote:
>
>> Thanks, but this app
nd split, etc?
Bill.
On 18 September 2015 at 20:52, Jameson Nash wrote:
> You should be able to work out everything relative to source_path() at
> compile time (this is what `include` does to find files relative to the
> current file being included).
>
>
> On Fri, Sep 18, 2015
Sorry, I didn't explain that well.
It is the location of deps/deps.jl that is not at a constant location
_relative_ to the current working directory, which could be anything. I
can't hard code it to an absolute path since that will just break on
someone else's machine.
The whole point of the deps
Sorry, it's complaining about the ccall,not the cglobal.
I has this code inside of init.
ccall((:pari_init, "$pkgdir/local/lib/libpari"), Void, (Int, Int),
30, 1)
It looks like it is complaining about the string interpolation. I guess it
needs to know the exact string at compile time
Hi,
I'm actually trying to precompile our library. This seems to necessitate
putting some of the initialisation code we had in an __init__ function.
But I'm having problems with the cglobal syntax.
According to the documentation, it takes a tuple with exactly the same
format as ccall.
But this
All 23,000 lines of code in our Nemo package passes its extensive test
suite with Julia-0.4-rc1 on Ubuntu 14.04 and Windows 10 (64 bit).
Thanks all for the amazing hard work!
Bill.
On 11 September 2015 at 06:18, Nitin Arora wrote:
> Congrats all !
>
>
> On Thursday, September 10, 2015 at 10:21
which builds msys-2.0.dll into the other dlls I'm building.
>>>>
>>>> Bill.
>>>>
>>>> On 15 September 2015 at 03:58, Jameson Nash wrote:
>>>>
>>>>> You can use a program called depends22.exe to check whether it has any
at 04:30, Jameson Nash wrote:
> The shell is correct, but you will probably want to download mingw64
> separately. The julia `README.windows` file has links, I think, to the
> right one to download.
>
> On Mon, Sep 14, 2015 at 10:27 PM 'Bill Hart' via julia-users <
>
exe to check whether it has any
>>> odd dependencies. Then try calling just
>>> `dlopen("C:\\absolute\\path\\to\\lib.dll")` and see whether that works.
>>> ccall uses the same underlying dlopen call, so once you get it working for
>>> one, it should
d depends22.exe to check whether it has any odd
> dependencies. Then try calling just
> `dlopen("C:\\absolute\\path\\to\\lib.dll")` and see whether that works.
> ccall uses the same underlying dlopen call, so once you get it working for
> one, it should work for both.
>
> O
I tried two different dll's with absolute paths, built with recent MinGW64
and Julia's ccall does not work for either. It still says, "The specified
module could not be found".
The file type is "gmp-6.0.0/.libs/libgmp-10.dll: PE32+ executable (DLL)
(console) x86-64, for MS Windows" and it is just
On 15 September 2015 at 02:54, Tony Kelman wrote:
> On second thought ECOS.jl is a simpler example:
> https://github.com/JuliaOpt/ECOS.jl/blob/master/deps/build.jl
>
> Or MbedTLS.jl, very similar but with multiple libraries:
> https://github.com/JuliaWeb/MbedTLS.jl/blob/master/deps/build.jl
>
>
>
I forgot to ask: does Julia currently expect to find .a or .dll files on
Windows 64? Is anything else needed?
Bill.
On 15 September 2015 at 02:23, Bill Hart
wrote:
> Hi,
>
> I'm currently up to working on building the dependencies for our Nemo
> computer algebra package for Julia:
>
> https://g
Hi,
I'm currently up to working on building the dependencies for our Nemo
computer algebra package for Julia:
https://github.com/wbhart/Nemo.jl
We have dependencies on the following C libraries:
libpari (Pari/GP)
Antic (https://github.com/wbhart/Antic)
Flint (https://github.com/wbhart/flint2)
m
101 - 158 of 158 matches
Mail list logo
