Is it possible to change any MPI settings during runtime? The only similar thing I know about is manipulation with intra and inter-communicators (docs).
Do you know about some other things? I'm thinking about changing PATH, MPIEXEC_TIMEOUT, prefix of PATH etc.
I need it just for demonstration purposes for one project, so anything that can be set during runtime, is enough :-)
The now standard way of doing this is with control variables (CVARs). These are all implementation specific, so you'll have to look in the documentation for your particular library. Often, these can be set with an environment variable.
For example, in MPICH 3.2, there is an environment variable called MPIR_CVAR_ASYNC_PROGRESS that allows you to turn on and off asynchronous progress at runtime. These things are documented in the tarball in a file called README.envvar.
These things will not be consistent between implementations so you'll have to be careful about names depending on where you are running. For instance, in Open MPI, I'd imagine that most of these environment variables will be prefixed with something like OMPI_something since that's more in line with the naming scheme used by that project.
Related
Let's say that I don't care to give the full path in each source, when would I choose tcl package over tcl source? is package require faster than source?
I know what the packages protects us from sourcing the code twice, is that a problem? I'm only sourcing functions, so I don't mind the functions to be sourced twice, but it there a performance issue with this?
Of course there is a performance issue.
Think about what happens when you run a source command:
The path supplied to the source command must be opened.
The operating system checks the path for permissions, resolves symbolic links.
This is minor for your particular case.
This can be a major hit for some applications that check file paths over and over
(e.g. web servers).
The file is read in.
Disk I/O. Always slow.
The file is parsed, and interpreted.
Parsing is always slow.
Tcl has a simple rule set, so its parsing is probably faster than some.
Since your functions are replaced...
The issue here is that the byte code compiler now forgets any optimizations
that were in place and the function will run slower than usual the first time
it is used.
Always be aware of what resources (cpu, disk, memory, network) your program is using, and try to minimize the usage.
Opinion: You will find people that just say, "get better hardware". These people are fools and this is the reason why most of the web is so slow. They waste resources needlessly.
Looking at your core question:
Is package require faster than source?
They're not directly comparable.
Packages are a higher-level concept than script files you can source, and are often implemented by sourceing a file or few. There is also a caching mechanism, so that while the first time you do a package require it will be definitely substantially slower than source (as the package management subsystem needs to search through the packages you've got if it doesn't recognise the one you ask for, which actually involves using source on quite a few pkgIndex.tcl files) subsequent calls to package require are probably faster, as packages are not loaded in twice. Once the internal index is built (a normally once-per-interpreter cost), package require of a known but not loaded package is not much slower than directly sourceing its implementation files. Except there's that “higher level” thing going on: the package may not be implemented by things you can source at all, and might instead be using load of a DLL. Or it could do a mix. That's the package's business: all you usually need to know is that the functionality has a name and version. That contrasts with direct source, where you need to know exactly where the code is (OK, easy if it is in a known fixed location or is located relative to the current script) and also that that file is exactly what you need. In general, it's better to split policy (e.g., package require foobar 1.2.3) from implementation (e.g., source -encoding utf8 /usr/local/lib/tcl/packages/foobar_1.2.3/foobar.tcl).
A consequence of packages being a one-time thing is that they're not intended for making instances of objects and object-like things (except for those that are effectively documented singletons in the API). You package require to get the construction commands (which might be classes) and then you use those commands to make the instances that you need when you need them.
The Gentoo's ebuild mecanism comes with several built-in eclasses/commands to manage (amongst others) libraries, binaries, executables, etc... Some of them are really useful to work at installation phase, like setting permissions, modifying the default installation directory, etc...
About library installation, the ebuild documentation says :
dolib [list of more libraries]
Installs a library or a list of libraries into DESTTREE/lib. Creates all necessary dirs.
libopts [options for install(1)]
Can be used to define options for the install function used in the dolib functions. The default is -m0644.
The same is available for "executables": exeopts works with doexe.
Question
The thing I really don't understand is that why dobin and dosbin exist but not binopts and sbinopts?
Is it possible have libopts or exeopts equivalents for dobin and dosbin, to manage permissions at installation phase?
Because dobin and dosbin are special cases of doexe, which have pre-defined options; if you need special permissions (e.g. suid) you can use doexe as needed.
Effectively (/usr)/bin and (/usr)/sbin should be executable to all users, unless something special (like limiting access to a group that has access to the hardware) is needed.
(I would probably be in favour of removing libopts too, but that's a different story, I guess.)
I have a go app which relies heavily on static resources like images and jars. I want to install that go executable in different platforms like linux, mac and windows.
I first thought of bundling the resources using https://github.com/jteeuwen/go-bindata, but since the files(~100) have size ~ 20MB or so, it takes a really long time to build the executable. I thought having a single executable is an easy way for people to download the executable and run it. But seems like that is not an effective way.
I then thought of writing a installation package for each of the platform like creating a .rpm or .deb packages? So these packages contain all the resources and puts it into some platform specific pre defined locations and the go executable can reference them. But the only thing is that I have to handle that in the go code. I have to see if it is windows then load the files from say c:\go-installs or if it is linux then load the files from say /usr/local/share/go-installs. I want the go code to be as platform agnostic as it can be.
Or is there some other strategy for this?
Thanks
Possibly does not qualify as real answer but still…
As to your point №2, one way to handle this is to exploit Go's way to do conditional compilation: you might create a set of files like res_linux.go, res_windows.go etc and put a set of the same variables in each, pointing to different locations, like
var InstallsPath = `C:\go-installs`
in res_windows.go and
var InstallsPath = `/usr/share/myapp`
in res_linux.go and so on. Then in the rest of the program just reference the res.InstallsPath variable and use the path/filepath package to construct full pathnames of actual resources.
Of course, another way to go is to do a runtime switch on runtime.GOOS variable—possibly in an init() function in one of the source files.
Pack everything in a zip archive and read your resource files from it using archive/zip. This way you'll have to distribute just two files—almost "xcopy deployment".
Note that while on Windows you could just have your executable extract the directory from the pathname of itself (os.Args[0]) and assume the resource file is located in the same directory, on POSIX platforms (GNU/Linux and *BSD etc) the resource file should still be located under /usr/share/myapp or a similar place dictated by FHS (or particular distro's rules), so some logic to locate that file will still be required.
All in all, if this is supposed to be a piece of FOSS, I'd go with the first variant to let the downstream packagers tweak the pathnames. If this is a proprietary (or just niche) software the second idea appears to be rather OK as you'll play the role of downstream packagers yourself.
I work on software that requires access to DLLs, usually wants environment variables set a certain way, and can take command line parameters. I'm generally opposed to setting/modifying system-wide environment variables for the purpose of launching these apps, since I might want to use different dependencies (different dlls), etc. and I don't want to accidentally get the wrong DLL loaded.
Up until now, I've been generating the visual studio .vcproj.user files and matching batch files from cmake ( see here for my script ) that extends the path to include the path to my dlls, sets any other environment variables as needed, and launches the application, forwarding all the command line arguments. (I do the same on Linux, but it's simpler because of RPATH). When we want to launch with a command line argument that wasn't just a file we could drop on the batch file, what we did is copy the batch file and edit the command to add our argument. (It's all GUI applications, but config files/flags can be passed on the command line)
This has become quite a hassle for me and my colleagues, and we end up with a ton of batch files, named similarly and difficult to maintain. It's not really a great interface for starting but there's a lot of apps we either use or develop that are like this, so it's a common task.
My question is this: I'd like a nicer way to configure dynamic library search paths, process-local environment variables, working directory, executable, and arguments for starting a program than hand-editing a batch file every time. I've done some digging to try to find one, but haven't been successful - "launcher" tends to bring me to "search-as-you-type" tools for frequently-used apps, and "command line argument" tends to find recommendations to use batch files. (It's not a windows-specific issue, either, but the dynamic library path stuff is less problematic during the code/compile/run cycle)
I've made a quick mockup of what I'm envisioning: it seems like the kind of thing that has to exist somewhere. Do you know of a tool similar to this (preferably cross-platform, and open source is even better)? It doesn't need all bells and whistles I put in the mockup, but that's what I'd build if I had time to build it myself. Thanks!
Hi what is the main need for setting an Environment Variable, while we have been installing many languages. What's there need? And does the installation cant set(in case of java)? Why so?
Environment variables are set to allow access to command line tools and to enable other tools to interact with SDKs more easily. For example, with Java on Windows, if the environment variable is not set on the PATH, running javac is much more cumbersome because you need to type in the full path to the command each time:
C:> \jdk<version>\bin\javac MyClass.java
In Java setting the environment variables isn't required; it's just easier. Other languages may be more stringent, though I haven't seen any specific examples I could cite. You can read the article How Do I Set the Path System variable? for specifics on how to do this.
The Java installer doesn't change the path variable, but other tools do (Microsoft's own, for example). I assume it's a design decision on the part of Sun/Oracle rather than any particular technical limitation.
In case of JAVA You can run the JDK just fine without setting the PATH variable, or you can optionally set it as a convenience. However, you should set the path variable if you want to be able to run the executables (javac, java, javadoc, and so on) from any directory without having to type the full path of the command. If you do not set the PATH variable, you need to specify the full path to the executable every time you run it.
windows make the Environment variable because of access and organize promotions to users and protection
hope this will h e l p you