I realise my original question should have been more specific and not digress about implementing fast globals. Please bear with me as I'm relatively new to programming let alone Julia (from my little experience I quite like Julia) Any guidelines on best practice would be appreciated, but I'll also ask some specific questions below. I guess conceptually I have a lot of "global" parameters that usually don't change much. I also have tried to define short, one-purpose functions (which I believe is encouraged?) These functions are called in many places and most have specific arguments but also access the "global" parameters My current implementation uses Julia global variables these parameters, which has 2 benefits for me:
- Easy to setup and leads to simpler code. - Global parameters are accessible from REPL (or in my case Juno LT), which allows interactive work. However using global variables probably leads to poor performance. And probably poor program design? I'm quite happy to not use globals, but I'm not sure about the best way to go about this. In any case, my next incarnation was to define a composite structure [ GlobalParameters] and instantiate as a global variable [g = GlobalParameters() # constructors initialises all fields]. Within functions, I access global parameters from this global composite type variable [g.field] - g is not passed as argument to function, but accessed as global This improved performance. However, I wondered whether there was any real type stability improvement, since variable is still global. Then I declared the global variable as const. [const g = GlobalParameters()] This appeared to lead to a further speedup. Q1. Are globals slow solely because type cannot be determined or guaranted? or is it also because globals are slower for other reasons as well? Q2. Can you verify that declaring global composite type as const should theoretically lead to better performance? Q3. Would there be further benefit from passing composite type as argument to all the functions? If anyone wants to provide general tips or best practice (general programming or Julia specific) I would welcome that as well. Thanks! Greg On Tuesday, December 16, 2014 8:40:50 AM UTC+11, Greg Plowman wrote: > Hi, > > I understand using global variables can lead to poor performance. > This is because types cannot be guaranteed? Globals could be reassigned > with different types? > > For my purpose, I set up a lot of parameters as global variables. > Then define lots of functions that have specific arguments but also use > some subset of the globals as well. > > I guess the response is going to be: do not to use globals. I get that. > However, to me it seems sometimes a natural and easy way to think about > program a solution. > > What are the alternatives: > > 1. Live with poor performance > 2. Create composite type containing the global variables, and pass > around a reference to single global variable of this composite type > - Would this boost performance? > - Would it boost performance if I didn't pass the composite-type > variable as argument, but instead access it inside functions as a > global > variable? > 3. What else? > > > > To compare performance, in some functions I assigned global variables to > local variables annotated with type. Then used local variable in > function. This produced a considerable speed-up, between 3-4x faster. > > function foo(arg1::arg1type, ...) > l_var1::var1type = g_var1 > l_var2::var1type = g_var2 > ... > > x = l_var1 * ... > end > > > > Can I do something like the following with equivalent speedup? > > function foo(arg1::arg1type, ...) > g_var1::var1type > g_var2::var2type > ... > > x = g_var1 * ... > end > > This would be sort of like declaring global variables as arguments to > function but with types. > Compiler could optimise. Runtime error if type not correct. > > > > As an aside, it occurred to me that there might be 2 cases for global > variables. > > 1. globals used in interactive REPL environment, where global can be > reassigned > 2. globals used for bad or lazy or whatever programming > > Why can't we have static *type* globals? Not const but const type. > So effectively, we have 3 levels of const/variable-ness > > global x = 5 > x = 6 # OK > x = 9.1 # OK > > static x = 5 > x = 6 # OK > x = 9.1 # ERROR, must release/clear/reset x first > > const x = 5 > x = 6 # ERROR > x = 9.1 # ERROR > > > > > Cheers, Greg >
