Isn’t this just @unpack from Parameters.jl?
1 Like
The difference is as follows:
@unpackall_Foo foo
@unpack a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z = foo
It’s hard to be forced to use the latter style, so it would be great if someone clever could create a package to use the former style.
Sample code
Create a composite type with a lot of fields:
using ConcreteStructs
@concrete struct Foo a; b; c; d; e; f; g; h; i; j; k; l; m; n; o; p; q; r; s; t; u; v; w; x; y; z end
names = fieldnames(Foo)
kwargs = Expr(:parameters, (Expr(:kw, name, v) for (v, name) in enumerate(names))...)
@eval Foo($kwargs) = Foo($(names...))
foo = Foo(a = "meow", m = 'm', z = 99.99)
Output:
Foo{String, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Char, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Int64, Float64}(“meow”, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, ‘m’, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 99.99)
@unpackall_Foo case:
"""
`@unpackall_Foo(obj)` unpacks all fields of the object `obj` of type `Foo`.
"""
macro unpackall_Foo(obj)
names = fieldnames(Foo)
Expr(:(=),
Expr(:tuple, names...),
Expr(:tuple, (:($obj.$name) for name in names)...)
) |> esc
end
let
@unpackall_Foo foo
@show a b c d e f g h i j k l m n o p q r s t u v w x y z
end;
Output
a = "meow"
b = 2
c = 3
d = 4
e = 5
f = 6
g = 7
h = 8
i = 9
j = 10
k = 11
l = 12
m = 'm'
n = 14
o = 15
p = 16
q = 17
r = 18
s = 19
t = 20
u = 21
v = 22
w = 23
x = 24
y = 25
z = 99.99
Parameters.@unpack case:
using Parameters
let
@unpack a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z = foo
@show a b c d e f g h i j k l m n o p q r s t u v w x y z
end;
The output is the same as above.
Jupyter notebook: https://github.com/genkuroki/public/blob/main/0018/How%20to%20define%20unpacking%20macros%20Part%202.ipynb
1 Like
If you define your struct with @with_kw, Parameters.jl will also make a macro for you which does @upack_all. See here.
Note: I would definitely consider this an anti-pattern. If your function needs all of those variables in scope, it’s a sign you need to re-factor into smaller functions.
6 Likes
Oh! I hadn’t noticed that part of the documentation! Thank you very much.
(What I’m having a little trouble with is about the compatibility of Parameters.@with_kw and ConcreteStructs.jl. ([ANN] ConcreteStructs.jl)
I just put in a fix for ConcreteStructs to allow it to work with Base.@kwdef. Parameters.@with_kw doesn’t work, though.
About 500 lines or so. It is prototype algorithm but it works very well and robust.
But it will take me some time to appreciate the logic of Julia.
Thank you very much for your suggestions.
I used Julia 1.6.1. I used 3 methods as you suggested,
rn = rand(1)[1]
rn = rand()
const RNG = MersenneTwister(100)
rn = rand(RNG)
In my code it does not make difference. It looks like the bottleneck is not the random number generator. Julia 1.6.1 seems smart enough in running random number generator.
In my view, modern Fortran means the following:
- f90 and above. Use modules to arrange the whole program in a neat and clear way.
- implicit none, and use select kind to choose true real 8 or double precision.
- flexible arrays. Whenever possible prevent using hard coded array size. Set array size as a variable, use allocatable arrays when needed.
- Whenever possible, vectorize the code.
- Use types to organize objects.
- highly parallelized, especially MPI.
Thank you @Vasily_Pisarev @Sukera @genkuroki @DNF @lmiq @giordano @Henrique_Becker @ranocha @artkuo @ParadaCarleton etc (Sorry for the @ ten user limit…) Your help and comments are very crucial and very helpful!
The reason my Julia version is 3 times slower than Fortran, is probably because those const Ref stuff in my code caused a lot of unnecessary memory operations. Hopefully by removing them the code can reach the speed of Fortran.
I think Julia is promising. I also hope Julia can be more intelligent in optimizing the code when compiling. and do more @inline, @inbound, @turbo, @unpack, etc… tricks automatically. Personally I do not mind Julia spending some more seconds in compiling as long as it can do more optimization automatically.
In one word, I wish Julia could perhaps improve in a way that it can be more difficult for the user to write slow code.
3 Likes
Personally, I imagine something like a “performance” or “debug” mode which could, for example, throw warnings (or even errors?) when using non-constant globals or, as an option, errors on allocations in a certain block of code (useful for high performance engineering and embedded systems).
Note, though, that being able to write naive / slow / bad code is also an important feature, in particular for interactive usage.
6 Likes
Given that Julia’s design encourages highly abstract code, it’s hard to even define what code is slow without running it.
Even the simplest case
function sum_itr(itr)
s = 0
for x in itr
s += x
end
return s
end
is tricky: it is fast if itr has only integer values, and it has penalty due to type instability otherwise.
Such analysis is less of a problem when you have the end-user code where the types may be known at all call sites, but I can’t imagine a robust a priori performance analysis of a library code in a general case (but of course the library devs can include in the test suite the specific argument types they assume important / representative).
3 Likes
I really prefer my code to work first and performance can be continuously improved instead of re-writing it in a different language. It sounds like C/C++/Fortran are for you, where even the most verbose convoluted code is often not-too-slow
I hope we get a package that runs a function and just says, this is slow because of this etc. Basically an even more powerful Dispatch Analysis · JETTest.jl . It already is amazing, but I hope it can get even better.
5 Likes
I totally agree.
Having ''performance" mode and “Debug” mode is like the “Release” Mode and “Debug” mode of the intel Fortran in Visual Studio.
Wish Julia can throw more warning message when it finds some performance issues and tell user how to improve the code. In my point of view, being able to throw those ‘intelligent’ message can be really a “modern” feature for a modern language.
Also wish Julia could have its own official IDE which is easy to use and debug, this can make Julia distinguished more from things like Python too.
1 Like
Thank you very much for your efforts!
May I ask a stupid question, using the below structure as your said,
Uhm, why it will be faster than defining many variables each with the const + Ref trick as the `Fortran’ like way I did?
It seemed to me, from reading this thread, that using const + ref isn’t actually good for performance, maybe I got the wrong idea though
There are some nuances concerning that specific statement. But the take away is: Don’t use global variables!
5 Likes
True, I just think if OPs code was written in a Julian way (rather than writing it as you’d write it in Fortran) the performance would be equivalent. I’ve never seen const + ref used in Julia (not that I’ve written anything huge in Julia I just simulate things) so I was a bit skeptical 
Yes, if the code was written more properly in Julia, the performance should be similar.
If you use const + ref to define scalars, is like defining every scalar as a one-element array, with a specific position in heap memory, carrying a pointer. Scalars do not need that, they are immutable and that allows many compiler optimizations.
3 Likes
It’s not about performance, it’s about easy identification of a global variable used in a function, to facilitate further refactoring.
Continuing your analogy to video games difficulty level, the rules of the game include “No global variables. Period.” and you have to build your solution around that. Maybe find some module of yours with less than ten global variables and refactor that one first to get the hang of it. You’re really missing good bits of Julia with the Fortran approach IMO, like using return to return useful values, default argument values, keyword arguments, structs to organize computations etc.
3 Likes
I guess field mu and sigma of the struct Mean_cov are actually 2x2 array, right? We can make this faster by defining Mean_cov as:
struct Mean_cov
mu::SMatrix{2, 2,Float64,4}
sigma::SMatrix{2, 2,Float64,4}
w::Float64
end
and make Mean_cov immutable, so it can be stored inline in array (with the price that we can’t mutable them).
1 Like