## How To Compute a Base-Change in Logarithms

One of the problems people may face in Computer Science, is a CPU only capable of computing a logarithm in one base, say 2, but the need to compute a logarithm in another base, say (e). The way to convert is as follows:

c log2(t) == logb(t)

If (t == b), it follows that:

c log2(b) == logb(b) == 1

Hence,

c = 1 / log2(b)

Dirk

## Power failure tonight, downtime.

This evening, Montreal experienced a forecast, severe thunderstorm. But what could not be forecast with certainty, was whether the power would fail, in my exact neighborhood. In fact, it did.

I take the somewhat unusual approach, of hosting my Web-site, and therefore also this blog, on my PC at home. The availability of this blog can therefore not be any better, than the availability of my PC, to the Internet. Therefore, this site and blog were briefly offline, from about 19h00 until 20h00. I apologize for any inconvenience to my readers.

Dirk

## About the LuxCore Renderer, and OpenCL Rendering.

One of the subjects which I’ve written about before, is that On one of my computers, the 3D Graphics Application ‘Blender’ is set up, optionally, to use ‘LuxCore’ to render a scene, and that the main feature of LuxCore which I’m interested in, is its ability to render the scene using OpenCL, and therefore using the GPU cores, rather than just using CPU cores.

A curious question which some of my readers might ask would be, ‘How does the user know, that LuxCore is in fact using the GPU, when he or she has simply selected OpenCL as the rendering hardware?’

In my case, the answer is the fact, that my GPU-temperature increases dramatically. And when I perform any type of GPU computing, the GPU temperature does same. I’ve had the GPU get 70⁰C hot, while, when idling, the GPU-temperature will not exceed 40⁰C. It can be observed though, that when OpenCL rendering is selected, all 8 CPU cores are also in-use, and that may just be a way in which LuxCore works. Further, it may be  away in which OpenCL works, to make the CPU cores available, in addition to the GPU cores.

Dirk

## I’ve just tweaked my kernel memory a little.

According to This previous posting of mine, I had set aside 270MiB of RAM, just in case the kernel needed it, on the computer I name ‘Phoenix’, to keep track of user-space programs, watching files and directories. I had also taken A Quick Glance at the way 64-bit kernel, virtual memory is organized under Linux, differently from how 32-bit virtual addresses were. Given the additional fact, that I only want to set aside 128MiB of user-space RAM, To cache my blog’s Web-pages, I decided that the earlier amount of kernel-memory was too large.

And so now I’ve reduced the amount, for ‘INotify’, to a mere 135MiB.

This computer has 4GiB total RAM.

Elaboration:

On 32-bit systems, the entire address space only had 4GB, but under no circumstances was the kernel expected to take up more than 1 GB. The computer ‘Phoenix’ is a 64-bit system, but one which only has 4GB of physical RAM. Therefore, even though it’s a 64-bit system, its kernel should still not take up more than 1GB. Yet, if I preallocate 270MB, just to perform one task, I’m pushing this system’s kernel closer to using up 1GB for real. So just for this one task, I’ve reduced this one commitment to 135MB.

Dirk