Re: [julia-users] Re: Symbols as Dict keys - efficiency / memory allocation?

at 10:32 AM, Yichao Yu <yyc1...@gmail.com <mailto:yyc1...@gmail.com>> wrote: On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz <oliver.sch...@tu-dortmund.de <mailto:oliver.sch...@tu-dortmund.de>> wrote: Hi Yichao I get that - I was just cu

Re: [julia-users] Re: Symbols as Dict keys - efficiency / memory allocation?

Thanks for the explanation, Yichao! On Wednesday, August 17, 2016 at 4:33:43 PM UTC+2, Yichao Yu wrote: > > > > On Wed, Aug 17, 2016 at 10:19 PM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Hi Yichao >> >> I get that - I was just curi

Re: [julia-users] Re: Symbols as Dict keys - efficiency / memory allocation?

ex into a global >>> array somewhere.. i.e. a pointer. Stack-allocating non-bits-type >>> immutables is on the roadmap to 1.0, so that should solve your problems. >>> >>> Maybe you can solve the CategorizedPoint problem by using an @enum. >>> >>

Re: [julia-users] Re: Symbols as Dict keys - efficiency / memory allocation?

he CategorizedPoint problem by using an @enum. > > On Wed, Aug 17, 2016 at 6:48 AM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Hello Andreas, >> >> consider iterating over a Dict{Symbol,Int64}: >> >> d = Dict(:foo => 42, :bar => 77

Re: [julia-users] Re: How to set JULIA_NUM_THREADS for remote workers?

Hi Bart, ~/.ssh/environment could work, but it's a bit too global for my taste. :-) Cheers, Oliver On Wednesday, August 17, 2016 at 1:11:43 PM UTC+2, Bart Janssens wrote: > > > > On Wed, Aug 17, 2016 at 12:53 PM Oliver Schulz <oliver...@tu-dortmund.de > > wrote: >

Re: [julia-users] Re: How to set JULIA_NUM_THREADS for remote workers?

Yup: https://github.com/JuliaLang/julia/issues/18074 On Wednesday, August 17, 2016 at 12:54:51 PM UTC+2, Jeffrey Sarnoff wrote: > > yep -- that sums it up, you could open an issue (on your issue). > > On Wed, Aug 17, 2016 at 6:52 AM, Oliver Schulz <oliver...@tu-dortmund.de >

[julia-users] Re: How to set JULIA_NUM_THREADS for remote workers?

> > so it seems environment variables are one of those nonsynced things > > -- Jeffrey > > > On Wednesday, August 17, 2016 at 5:17:53 AM UTC-4, Oliver Schulz wrote: >> >> Hi Jeff, >> >> > If your remote workers are remotely local invocations of Ju

[julia-users] Re: Symbols as Dict keys - efficiency / memory allocation?

x::Float64 y::Float64 category::Symbol end I would definitely want this to be a bits-type, and not have every instance heap-allocated. Cheers, Oliver On Wednesday, August 17, 2016 at 11:44:13 AM UTC+2, Andreas Lobinger wrote: > > Hello colleague, > > On Wednesday, August 17, 2016 at

Re: [julia-users] Determining L1 cache size?

out and another element in (for a filter algorithm). On Tuesday, August 16, 2016 at 8:02:30 PM UTC+2, Erik Schnetter wrote: > > Ooh! Yes, I need to register it. Thanks for the reminder! > > -erik > > On Tue, Aug 16, 2016 at 12:01 PM, Oliver Schulz <oliver...@tu-dortmund.de &

[julia-users] Re: How to set JULIA_NUM_THREADS for remote workers?

then the remote workers will be using > that many threads (if the have the cores). > > > On Tuesday, August 16, 2016 at 11:52:20 AM UTC-4, Oliver Schulz wrote: >> >> I guess the answer is "no", then? >> >> On Monday, August 1, 2016 at 3:26:17 PM UTC+2

[julia-users] Re: Symbols as Dict keys - efficiency / memory allocation?

August 16, 2016 at 11:44:46 AM UTC-4, Oliver Schulz wrote: >> >> Hi, >> >> I was thinking of using Symbols as keys in a Dict{Symbol,Int64}, instead >> of Strings. However, Symbol is not a bitstype, so there I guess there will >> still be a lot of individual

Re: [julia-users] Determining L1 cache size?

wrote: > > ```Julia > Pkg.add("Hwloc") > using Hwloc > topo = load_topology() > print(topo) > ``` > > I just see that Hwloc has problems with Julia 0.5; I'll tag a new release. > > -erik > > > On Tue, Aug 16, 2016 at 5:12 AM, Oliver

[julia-users] Re: How to set JULIA_NUM_THREADS for remote workers?

I guess the answer is "no", then? On Monday, August 1, 2016 at 3:26:17 PM UTC+2, Oliver Schulz wrote: > > Is it possible to pass on or explicitly set JULIA_NUM_THREADS for remote > workers started via > > addprocs([host1, ...]) > > ? > >

[julia-users] Symbols as Dict keys - efficiency / memory allocation?

Hi, I was thinking of using Symbols as keys in a Dict{Symbol,Int64}, instead of Strings. However, Symbol is not a bitstype, so there I guess there will still be a lot of individual memory allocation when working with such a Dict, right? Actually, why isn't Symbol a bitstype (according to

[julia-users] Determining L1 cache size?

Hi, is there a (cross-platform) way to get the CPU L1 cache size from Julia? I'd like to determine the optimal block size(s) for an array algorithm. Cheers, Oliver

Re: [julia-users] Changed broadcast semantics in 0.5?

/17314>. >>> >> >> ... and was just reverted, because it caused massive performance issues >> <https://github.com/JuliaLang/julia/issues/17794#issuecomment-237455407>. >> >> >> >>> >>> Cheers, >>>

Re: [julia-users] Changed broadcast semantics in 0.5?

eers, > Kevin > > On Mon, Aug 1, 2016 at 8:28 AM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Thanks, Pablo. Uh, do you think that PR will make it into 0.5? >> >> >> On Monday, August 1, 2016 at 3:41:23 PM UTC+2, Pablo Zubieta wrote: >&

Re: [julia-users] Changed broadcast semantics in 0.5?

Thanks, Pablo. Uh, do you think that PR will make it into 0.5? On Monday, August 1, 2016 at 3:41:23 PM UTC+2, Pablo Zubieta wrote: > > This should work if https://github.com/JuliaLang/julia/pull/17389 gets > merged. > > On Monday, August 1, 2016 at 3:06:36 PM UTC+2, Oliv

[julia-users] How to set JULIA_NUM_THREADS for remote workers?

Is it possible to pass on or explicitly set JULIA_NUM_THREADS for remote workers started via addprocs([host1, ...]) ?

Re: [julia-users] Changed broadcast semantics in 0.5?

ote: > > On Mon, Aug 1, 2016 at 8:41 PM, Oliver Schulz > <oliver...@tu-dortmund.de > wrote: > > So cases like > > > > broadcast((x,y,z)->..., A, B, C) > > > > can't be supported any longer? Darn. :-( I love the things you guys are > > doing

Re: [julia-users] Changed broadcast semantics in 0.5?

C+2, Yichao Yu wrote: > > On Mon, Aug 1, 2016 at 8:15 PM, Oliver Schulz > <oliver...@tu-dortmund.de > wrote: > > Hi, > > > > sorry if this is already covered somewhere - have the semantics of > broadcast > > changed in Julia 0.5? > > Essentia

[julia-users] Changed broadcast semantics in 0.5?

Hi, sorry if this is already covered somewhere - have the semantics of broadcast changed in Julia 0.5? In 0.4, I can do broadcast(muladd, rand(5), rand(5), rand(5)) But in 0.5 (0.5.0-rc0+86), I get ERROR: MethodError: no method matching muladd(::Float64, ::Float64) Closest candidates are:

[julia-users] Re: Combining @parallel and @threads

e @parallelthreads or something. > > -viral > > On Saturday, July 30, 2016 at 12:00:51 PM UTC+5:30, Oliver Schulz wrote: >> >> It would be nice if @parallel and @threads could be combined. E.g. in an >> expression >> >> @parallel @threads for [...] end &g

[julia-users] Re: Combining @parallel and @threads

this to work. If not in this form, with a different > macro like @parallelthreads or something. > > -viral > > On Saturday, July 30, 2016 at 12:00:51 PM UTC+5:30, Oliver Schulz wrote: >> >> It would be nice if @parallel and @threads could be combined. E.g. in an

[julia-users] Combining @parallel and @threads

It would be nice if @parallel and @threads could be combined. E.g. in an expression @parallel @threads for [...] end could it be possible for @parallel to "forward" @threads to the inner loops it produces? Does something like this exist already in some form? Forwarding @simd might also be

Re: [julia-users] Re: Writing code compatible with custom-indexed arrays

an issue? It might get more attention from > the > right parties that way. > > Best, > --Tim > > On Tuesday, July 26, 2016 5:03:31 AM CDT Oliver Schulz wrote: > > > Are you saying we should export what is currently _length? > > > > Well, maybe not

Re: [julia-users] Re: Writing code compatible with custom-indexed arrays

nic? Or are you worried that people will then start using (e.g.) 1:len(A) instead of 1:length(A), resulting in an even bigger mess? On Tuesday, July 26, 2016 at 1:47:57 PM UTC+2, Tim Holy wrote: > > On Tuesday, July 26, 2016 2:31:10 AM CDT Oliver Schulz wrote: > > I should have known y

[julia-users] Re: Writing code compatible with custom-indexed arrays

(A)) is just too unwieldy, IMHO. Cheers, Oliver On Tuesday, July 26, 2016 at 9:21:27 AM UTC+2, Oliver Schulz wrote: > > I was reading up on the new arrays with custom indices in 0.5. Now that > array indices do not implicitly start with one, what's the generic > replacement for index

[julia-users] Writing code compatible with custom-indexed arrays

I was reading up on the new arrays with custom indices in 0.5. Now that array indices do not implicitly start with one, what's the generic replacement for index ranges like A[2:end-1] Will there by something like A[start+1:end-1] or so? Also, since for safety reasons length(A) is now

Re: [julia-users] Fused-Multiply-Add function?

s only > sensible for matrices (as far as I can tell), there doesn't seem to be a > corresponding need for muladd! since the fusion is at the collection level. > > On Sat, Jul 23, 2016 at 2:31 PM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Oh, sure - I was actual

Re: [julia-users] Fused-Multiply-Add function?

e the fusion is at the collection level. > > On Sat, Jul 23, 2016 at 2:31 PM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Oh, sure - I was actually mainly thinking about matrices. I was looking >> for something like fma! in ArrayFire (without success), and then wo

Re: [julia-users] Fused-Multiply-Add function?

Yes, I know axpy. However - as far a I understand - that is explicitly a BLAS function. So it's not something that, e.g., a GPU library would provide specialized methods for. Also, axpy always results in a call, even for small arrays (please correct me if I'm wrong). I think in-place

Re: [julia-users] Fused-Multiply-Add function?

calars but they could be added for matrices. > > On Sat, Jul 23, 2016 at 1:54 PM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Hi Stefan, >> >> sorry, yes, I had somehow overlooked fma. Mainly I was looking for an >> in-place version though, like fma

Re: [julia-users] Fused-Multiply-Add function?

e systems be equivalent to x*y+z, or to fma(x,y,z). muladd is used to > improve performance. See fma. > > On Sat, Jul 23, 2016 at 1:40 PM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Does Julia have a standardized FMA (Fused-Multiply-Add) function? Like >> fma(A, B, factor) and fma!(dest, A, B, factor), so that that GPU libraries, >> etc. can provide optimized versions? >> > >

[julia-users] In-place version of fma (Fused-Multiply-Add)?

Does Julia have an in-place version of fma? I'm missing something like fma!(dest, x, y, z) - ideally with support for dest=x. It would seem to be something that GPU libraries (for examples) could provide optimized methods for (ArrayFire?).

[julia-users] Fused-Multiply-Add function?

Does Julia have a standardized FMA (Fused-Multiply-Add) function? Like fma(A, B, factor) and fma!(dest, A, B, factor), so that that GPU libraries, etc. can provide optimized versions?

[julia-users] Re: Intel MKL optimizations in default Julia builds?

ticles/julia-with-intel-mkl-for-improved-performance > > On Tuesday, April 26, 2016 at 10:16:24 AM UTC+2, Oliver Schulz wrote: >> >> Apparently, Anaconda 2.5 builds now ship with Intel MKL optimizations: >> >> >> https://www.continuum.io/blog/develope

[julia-users] Intel MKL optimizations in default Julia builds?

Apparently, Anaconda 2.5 builds now ship with Intel MKL optimizations: https://www.continuum.io/blog/developer-blog/anaconda-25-release-now-mkl-optimizations I wonder if this would be possible for the official Julia builds, too? I don't know about the MKL licensing conditions (and whether

[julia-users] Re: [ANN] Cuba.jl: library for multidimensional numerical integration

Very nice, Mose! I thought I might have to write a Julia wrapper for Cuba at some point, but you beat me to it (which I'm grateful for!). :-) I noticed that you're maintaining a modified version of Cuba for this - I guess because the upstream Cuba doesn't support "make shared"? Are you in

Re: [julia-users] Re: Large number of methods for a function and Julia for data acquisition

, 2016 at 6:57:23 PM UTC+2, Stefan Karpinski wrote: > > No worries. I just wanted to provide a link for context. > > On Sun, Apr 3, 2016 at 12:49 PM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >> Oh, darn - sorry, Stefan. I wanted to change the topic since the

Re: [julia-users] Re: Julia is a great idea, but it disqualifies itself for a big portion of its potential consumers

IMHO having the "/" operator return a float was an excellent design decision in Julia. The amount of time I've seen people waste (with other languages) tracking down bugs caused by doing a/b with a > I question the alleged ubiquity of integer division. This is not an > operation I find myself

Re: [julia-users] Re: Large number of methods for a function and Julia for data acquisition

es all context for this > message in most email systems. Groups seems to keep the message in context: > > https://groups.google.com/d/msg/julia-users/Dt6nbfhtaNQ/TCy6zT9HAAAJ > > On Sun, Apr 3, 2016 at 4:34 AM, Oliver Schulz <oliver...@tu-dortmund.de > > wrote: > >>

[julia-users] Re: Large number of methods for a function and Julia for data acquisition

Hi Andrew, On Saturday, April 2, 2016 at 7:10:00 PM UTC+2, Andrew Keller wrote: > > Regarding your first question posed in this thread, I think you might be > interested in this documentation > of how functions > will work in Julia 0.5

[julia-users] Re: Julia console with inline graphics?

On Saturday, April 2, 2016 at 2:46:51 PM UTC+2, Josh Day wrote: > > I believe that's iTerm being used with > https://github.com/Keno/TerminalExtensions.jl > . > >

[julia-users] Re: Can Julia handle a large number of methods for a function (and a lot of types)?

Hi Andrew, sorry, I overlooked your post, somehow ... On Monday, March 28, 2016 at 3:47:42 AM UTC+2, Andrew Keller wrote: > > Just a heads up that I've been working on something similar for the past > six months or so. > Very nice - I'm open collaborate on this topic, of course. At the moment,

[julia-users] Julia console with inline graphics?

Hi, I'm looking for a Julia console with inline graphics (e.g. to display Gadfly plots). There's Jupyter/IJulia, of course, but I saw a picture of something more console-like in the AxisArrays readme (at the end of

[julia-users] Re: Can Julia handle a large number of methods for a function (and a lot of types)?

Hi Jeffrey, On Sunday, March 27, 2016 at 3:51:18 PM UTC+2, Jeffrey Sarnoff wrote: > > Assuming your handshaking and signal management is keeping information > available in some easy to discern and decode manner and you are not pushing > latency issues, Julia should be a good platform for that.

[julia-users] Can Julia handle a large number of methods for a function (and a lot of types)?

Hello, I'm designing a scheme to control and read out hardware devices (mostly lab instruments) via Julia. The basic idea is that each device type is characterized by a set of features/properties that have a value type and dimensionality and that can be read-only or read/write (a bit like SCPI

[julia-users] Re: Easy way to precompile all installed packages?

on a compute cluster. On Friday, February 19, 2016 at 10:30:17 PM UTC+1, Steven G. Johnson wrote: > > > > On Thursday, February 18, 2016 at 7:33:49 AM UTC-5, Oliver Schulz wrote: >> >> But Base.compilecache compiles every time right, not just when necessary? >> So

[julia-users] Re: Easy way to precompile all installed packages?

compilecache may be more reliable here. > > > On Thursday, February 18, 2016 at 2:41:39 AM UTC-8, Oliver Schulz wrote: >> >> The best I've come up with so far is >> >> for pkg in vcat(["IJulia"], collect(keys(Pkg.installed( >> if !isdefined(Symbol(p

[julia-users] Re: Is the Actor model for parallelism a good paradigm for Julia

Hi, in case you're interested, I'm working on a Julia task/channel based actor framework: https://github.com/daqcore/Actors.jl It's registered, but still in an early stage and doesn't support inter-proccess/inter-host actor messages yet - though I hope to add that soon. Also, it probably will

[julia-users] Re: Easy way to precompile all installed packages?

bruary 17, 2016 at 12:58:10 PM UTC+1, Oliver Schulz wrote: > > Is there an easy way to precompile all installed packages, e.g. after a > `Pkg.update()`? > > This would come in handy when using a cluster of Julia machines (using an > shared home dir on a network filesystem)

[julia-users] Re: Easy way to precompile all installed packages?

Sure, that kinda works. Unfortunately, it doesn't include site-wide packages (resp. packages in LOAD_PATH). Is there a way to list all packages that are available to import/using? On Wednesday, February 17, 2016 at 2:20:21 PM UTC+1, Steven G. Johnson wrote: > > map(require,

[julia-users] Re: Easy way to precompile all installed packages?

Also, require gives a deprecation warning. ;-) On Wednesday, February 17, 2016 at 4:13:22 PM UTC+1, Oliver Schulz wrote: > > Sure, that kinda works. Unfortunately, it doesn't include site-wide > packages (resp. packages in LOAD_PATH). Is there a way to list all packages > that a

[julia-users] Easy way to precompile all installed packages?

Is there an easy way to precompile all installed packages, e.g. after a `Pkg.update()`? This would come in handy when using a cluster of Julia machines (using an shared home dir on a network filesystem), to ensure precompilation is done before all machines load (and start precompiling)

Re: [julia-users] Cxx.jl object address stability?

rantee that given future possible directions of the language, so for use > cases like this I would recommend keeping the object on the C++ heap so you > have explicit control over addresses. > > On Thu, Feb 11, 2016 at 7:09 AM, Oliver Schulz <oliver...@tu-dortmund.de > > wro

Re: [julia-users] Re: Cxx.jl object address stability?

Thanks, Yichao! On Tuesday, February 16, 2016 at 8:55:29 PM UTC+1, Yichao Yu wrote: > > > On Feb 16, 2016 2:38 PM, "Oliver Schulz" <oliver...@tu-dortmund.de > > wrote: > > > > Hello, > > > > I realized that this question is probably not

[julia-users] Re: Cxx.jl object address stability?

collector is non-moving. Should I be prepared for Julia to switch to a moving/compacting GC in the foreseeable future, or is a next-generation GC for Julia likely to be non-moving as well? Cheers, Oliver On Thursday, February 11, 2016 at 1:09:44 PM UTC+1, Oliver Schulz wrote: > &

[julia-users] Cxx.jl object address stability?

Hi, is the memory address (seen from C++) of objects created via `@cxx SomeClass()` (or similar) stable over time (GC cycles)? I need to use a container class whose elements keep a pointer to the container itself. I want Julia to own the container, so it should be subject to garbage

Re: [julia-users] Re: Packaging Julia project for Open Respoducable Science

Care (http://reproducible.io/) (based on PRoot, http://proot.me/) may also be an interesting option. I've used it before to pack up a complete Julia installation (including packages and required system libraries) on Ubuntu 14.04 and then run it on Scientific Linux 6. Care and PRoot are

[julia-users] Re: Make Julia package requirements depends on Julia version?

Hi Ian, Its definitely safe to have it on 0.4. Are you putting it in /REQUIRE or > /test/REQUIRE? You probably want to put it in the latter. (Apologies if I'm > telling you something you already know!) > In "/REQUIRE" - this is for EasyPkg (https://github.com/oschulz/EasyPkg.jl), so it's a

[julia-users] Re: Make Julia package requirements depends on Julia version?

Thanks, Tony! I'll just keep BaseTestNext in REQUIRE, then. Might be a useful feature for the future though, on occasion, to be able to mark a line in REQUIRE Julia-version dependent. Cheers, Oliver On Saturday, January 16, 2016 at 3:42:01 PM UTC+1, Tony Kelman wrote: > > Not easily. I think

Re: [julia-users] Re: RFC: ROOT.jl, wrappers for the ROOT library from CERN

rested, too? Cheers, Oliver On Wednesday, January 13, 2016 at 1:01:54 AM UTC+1, Oliver Schulz wrote: > > That's great news - thanks a lot, Keno! > > On Tuesday, January 12, 2016 at 4:24:33 PM UTC+1, Keno Fischer wrote: >> >> Doesn't work with ROOT-6, though, as t

[julia-users] Re: RFC: ROOT.jl, wrappers for the ROOT library from CERN

Hello, Keno's Cxx.jl is indeed awsome - was able to write a TTree (using ROOT-5) quite easily. Doesn't work with ROOT-6, though, as the LLVM instances of Cling and Julia seem to clash. I tried with your rjulia executable, Joosep, but that

Re: [julia-users] Re: RFC: ROOT.jl, wrappers for the ROOT library from CERN

That's great news - thanks a lot, Keno! On Tuesday, January 12, 2016 at 4:24:33 PM UTC+1, Keno Fischer wrote: > > Doesn't work with ROOT-6, though, as the LLVM instances >> of Cling and Julia seem to clash. >> > > I've been talking to the ROOT authors to get this resolved as well as > getting