The official reference implementation for Distributed Counter provided is for version 8 before the upgrade to modular.
How to use Distributed Counter on version 9 modular?
Related
I have been reading a while on the subject and I came across an article which left me a little bit lost on software versioning/releases.
If you follow it you will see it's just a list of all Symfony releases with their respective dates. What prompted me to ask this question was the fact that I could not get why/how, for example:
Symfony 2.8.37 released | April 2, 2018
while
Symfony 4.0.6 released | March 5, 2018
Symfony is just the example, my question applies to software versioning in general looking for an explanation to the above.
I am (am I?) positive that 2.8.37 is older than 4.0.6 so this most certainly has nothing to do with me comparing them wrong, surely there is a fundamental aspect about the versions release process I'm unaware of.
Finally, just to be sure, if I were to compare two versions, how would I go about it, I don't need a computer-language-specific-solution, just an algorithm in general to compare two given versions like you could do even using paper and pencil (I know, what a heathen).
Typically, 2.8.38 would be a security or other patch to 2.8.37; and 4.0.6 is a patch to 4.0.5, where 4.0 is a newer, more powerful base version that requires a different license or runs only under Windows 10 or some other reason why some people would like to stay on the old version.
The patch to the current version would be published faster, and then the team adds the important security patch to the older versions.
Symfony has very good support for old versions of their framework. Basically Symfony 2 was released and went through various version changes similar to 2.1 -> 2.2 etc. All the while maintaining compatibility with previous Symfony 2 projects.
Further down the road Symfony 3 was released, and while a Symfony 2 project could be updated to a Symfony 3 project it involves some work and there can be project breaking coding changes required. Then Symfony 3 progress 3.1 -> 3.2 etc.
Just because Symfony 3 is out and available doesn't mean that all work or bug fixes are done on Symfony 2. So there will still be releases of Symfony 2, in addition to releases of Symfony 3. Here is a visual view from the Symfony Page to show the version overlaps.
This is common with most software, for example Microsoft Windows 10 is the current version but Microsoft still provides patches for Windows 7.
For Berkeley db, some distro like fedora have both libdb4 and libdb(version 5), so why is this, is version 4 not compatible with future versions? Does my application need to support both versions?
There was a log file format change between version 4 and 5 that requires an upgrade. Essentially, yes, version 4 databases are not strictly compatible with the version 5 runtime. The on-disk data must be upgraded. Not all applications are ready to handle this, so libdb4 is still floating around.
You can find the changelog on Oracle's BDB site, here: http://www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.html
BDB version 6 has been out for about four years now. That's not much time in the life of a 20+ year old database. So, if you're finding that version 5 is still the widely distributed version (it probably is), then you should write your application to that. It has numerous bugfixes. If you want maximum compatibility with (much) older distros, write your application to version 4.
The new OpenMP 4 library now allows to use accelerators such as GPGPU.
Is OpenMP 4 implemented on top of OpenCL for these kind of tasks?
In some cases, yes. See TI's OpenMP Accelerator Model runtime implementation as an example. This is due to the fact that OpenCL is a mature standard with significant infrastructure. OpenMP accelerator support is new in version 4.0, so vendors are scrambling to add support.
My application is OpenCL 1.1 compatiable and I want to check whether each of the device has drivers for that version. There are 2 ways for this:
clGetDeviceInfo() ->CL_DEVICE_VERSION
clGetPlatformInfo() ->CL_PLATFORM_VERSION
I have following doubts:
I do not understand why method 1 is provided as method 2 seems the
correct way to me?
Is it possible that the version given by the platform will not
match with the version given by a device from the same platform?
What is clGetDeviceInfo::CL_DRIVER_VERSION for?
From all these options which one should I use to check if a device
can run my OpenCL 1.1 code?
There are some features in OpenCL that have hardware requirements. This means that even if a particular vendor's OpenCL implementation (the platform) supports an OpenCL version, the device might not. So, it is entirely possible for the versions returned from the CL_DEVICE_VERSION and CL_PLATFORM_VERSION queries to differ.
This will probably start to happen more frequently when OpenCL 2.0 implementations start appearing, as there is plenty of hardware on the market that doesn't have the necessary support for OpenCL 2.0 features. Imagine a system that has two devices from Vendor X: a new Device A that can run OpenCL 2.0, and a much older Device B that can't. In this instance, the platform version may be OpenCL 2.0, but the device version could be OpenCL 2.0 for Device A and OpenCL 1.2 for Device B.
The CL_DRIVER_VERSION is for getting a vendor specific version number for the implementation. This number could using any version numbering system that the vendor uses to keep track of different software releases, and is completely independent from OpenCL version numbers (although some vendors may well include the OpenCL version here too).
So, in order to be sure that both the device and platform support your required OpenCL version, you should just need to check CL_DEVICE_VERSION.
Is there some way to use thread pool with Qt 4.3? I know it has now been implemented in Qt 4.5. But is it somehow available in Qt 4.3 also?
Get the first version of QtConcurrent from the Qt Labs project. This version of QtConcurrent is compatible with Qt4.2 but 4.3 is recommended .
From Qt Labs ...
Qt Concurrent
Platforms: Windows, Linux, Mac Qt
version: 4.2 required, 4.3
recommended.
Qt Concurrent is a C++
template library for writing
multi-threaded applications. Qt
Concurrent provides high-level APIs
that makes it possible to write
multi-threaded programs withouth using
low-level threading primitives such as
critcal sections, mutexes or wait
conditions. Programs written with Qt
Concurrent automaticallly adjust the
number of threads used according to
the number of processor cores
available. This means that
applications written today will
continue to scale when deployed on
multi-core systems in the future. The
library includes functional
programming style APIs for for
parallel list prosessing, a MapReduce
implementation for shared-memory
(non-distributed) systems, and classes
for managing asynchronous computations
in GUI applications. The code can be
checked out with subversion: svn
checkout
svn://labs.trolltech.com/svn/threads/qtconcurrent
qtconcurrent If you don't have svn,
you can download a package instead.
You could get the 4.5 source code and rip it out from there. If they use their own API, it should be easy.
You can always use straight pthreads API in C/C++ with QT and implement your own thread pool.
Although you are probably looking for a solution involving less amount of work.