My personal answer, to whether Hyper-Threading works under Linux.

I have been exploring this subject, through a series of experiments written in Python, and through what I learned when I was studying the subject of System Hardware, at Concordia University.

When a person uses a Windows computer, this O/S provides all the details of scheduling processes and threads. And arguably, it does well. But when a person is using Linux, the kernel makes all the required information available, but does not take care of optimizing how threads are scheduled, specifically. It becomes the responsibility of the application, or any other user-space program, to optimize how it will take up threads, using CPU affinity, or using low-level C functions that instruct the CPU to replace a single line in the L1 cache

In the special case when a person is writing scripts in Python, because this is an interpreted language, the program which is actually running, is the Python interpreter. How well the scheduling of threads works in that case, depends on how well this Python interpreter has been coded to do so. In addition, how well certain Python modules have been coded, has a strong effect on how efficiently they schedule threads. It just so happens that I’ve been lucky, in that the Python versions I get from the Debian repositories, happen to be programmed very well. By other people.

Dirk

 

Refining my Python, for generating strong prime numbers…

According to an earlier posting, I had applied the (probabilistic) Miller-Rabin test, after testing whether large prime number candidates are divisible by any in a list of smaller, definite prime numbers, to generate pseudo-random numbers first, and then to continue until one was found to be prime.

That earlier effort had numerous issues, including the fact that it did not generate the kind of strong prime numbers needed for Diffie-Hellman key exchange. I have broadened my horizons slightly, and written more-up-to-date Python 3, which will generate such strong primes, as well as computing the resulting, Primitive Root, which would be used as the generator (g), if the results were ever actually used in cryptography.

I’d like to thank my friend, François Dionne, for giving me help with this project.

The resulting Python script can be downloaded from this URL:

http://dirkmittler.homeip.net/text/Generate_Prime_DMFD_ITC.py

(Updated 5/23/2019, 18h40 : )

Continue reading Refining my Python, for generating strong prime numbers…

Solving the recent Firefox ESR problem, with the Expired Extension Signing Certificate.

One of the problems that befell (almost all) Firefox users, midnight from May 3 to May 4, 2019, was, that many extensions which we had installed had suddenly become deactivated because an Intermediate Certificate used to sign those extensions, had simply expired. Apparently, somebody overlooked that status of the certificate in question.

To remedy this situation as quickly as possible, Mozilla offered to publish a “Study”, which is a kind of project that Firefox users can subscribe to, and the purpose of which usually is, to allow Mozilla to conduct experiments on users’ browsers. This study had as purpose however, just to install a renewed certificate.

One important piece of advice is, ‘If you are still experiencing this issue, Do not try to uninstall and reinstall the extensions. Doing so would delete all the data stored with the extensions, while simply to have them disabled, and then to have them re-enabled, will allow most extensions to keep their stored data!’

Therefore, to receive this fix, what Firefox users were advised to do, was to go into ‘Tools -> Preferences -> Privacy & Security’, and there, to Enable Studies. The problem which I experienced myself was, that this advice was not narrowed enough, for Linux users with ‘Firefox ESR’. First of all, the Linux versions of Firefox have their Preferences sub-menu under ‘Edit’, not under ‘Tools’, but that was the least significant problem. What was worse was that, under my Linux distribution, the option we were advised to check was greyed out, and could not be checked:

Screenshot_20190505_075343

(Edit 5/10/2019, 22h10 : )

Because as of this time, under Debian / Jessie as well as under Debian / Stretch, the official fix for this problem has been pushed through the package repositories, it’s no longer advisable by any means to apply the workaround described here. However, the update under Debian / Stretch was a bit slow in coming, for which reason this workaround served me well.

(End of Edit.)

However, I was able to get this feature of Firefox ESR to work anyway. And what follows is how I did that…

(Updated 5/06/2019, 16h00 … )

Continue reading Solving the recent Firefox ESR problem, with the Expired Extension Signing Certificate.

ArrayFire 3.5.1 Compiled, using GCC 4.9.2 and CUDA – Success!

A project which has fixated me for several days has been, to get the API which is named “ArrayFire” custom-compiled, specifically version 3.5.1 of that API, to enable CUDA support. This poses a special problem because when we use the Debian / Stretch repositories to install the CUDA Run-Time, we are limited to installing version 8.0.44. This run-time is too old, to be compatible with the standard GCC / CPP / C++ compiler-set available under the same distribution of Linux. Therefore, it can be hard for users and Debian Maintainers alike to build projects that use CUDA, and which are compatible with -Stretch.

Why use ArrayFire? Because writing kernels for parallel computing on the GPU is hard. ArrayFire is supposed to make the idea more-accessible to people like me, who have no specific training in writing highly parallel code.

When we install ArrayFire from the repositories, OpenCL support is provided, but not CUDA support.

I’ve hatched a plan by which I can install an alternative compiler set on the computer I name ‘Phosphene’, that being GCC / CPP / C++ version 4.9.2, and with which I can switch my compilers to that version, so that maybe, I can compile projects in the future, that do use CUDA, and that are sophisticated enough to require a full compiler-suite to build.

What I’ve found was that contrarily to how it went the previous time, this time I’ve scored a success. :-)  Not only did the project compile without errors, but then, a specific Demo that ships with the source-code version, that uses the ability of CUDA to pass graphics to the OpenGL rendering of the GPU, also ran without errors…

Screenshot_20190501_160413

So now I can be sure that the tool-chain which I’ve installed, is up to the task of compiling highly-complex CUDA projects.

(Update 5/03/2019, 7h30 : )

Continue reading ArrayFire 3.5.1 Compiled, using GCC 4.9.2 and CUDA – Success!