adrian_b

Any CPU generates more heat when it does more work, e.g. when more cores are active, or when using vector instructions.

Using the AVX-512 operations is much more efficient, i.e. the same amount of work can be done by consuming less energy. For instance, if you have a program running an AVX computation on 4 cores, you could double the throughput either by using AVX-512 or by using 8 cores, but the former variant will produce less heat.

For an overclocked system, where the normal power limits of the CPU are disabled, so it can consume a power great enough to exceed the capability of the cooler, it may make sense to disable AVX-512, for fear that one could run accidentally some program that is aware of AVX-512 and which would achieve a greater speed by using it, while also exceeding the power consumption that can be handled by the existing cooler.

On the other hand, on a non-overclocked system or in an overclocked system with a very capable cooler, disabling AVX-512 is always a mistake, which can only increase the average power consumption.

Yes, they have used GLM 5.2, which promptly did whatever they asked it to do, while their first attempts to use their enterprise access to a "SOTA" model failed due to refusals to investigate anything that is security related.

Intel Panther Lake is a serious improvement over the previous Intel CPUs, both in energy efficiency and in GPU performance. The good energy efficiency is a good sign for Intel's 18A CMOS fabrication process.

Nevertheless, it is worrying that the computers with Panther Lake CPUs have become much more expensive in comparison with their equivalents of last year with Arrow Lake, and this before adding the hugely increased costs for DRAM and SSDs.

It is also confusing for buyers that the 300-series Panther Lake part numbers that appear to be replacements for the previous 200-series Arrow Lake in most cases correspond to lower technical specifications, i.e. a much smaller GPU and lower clock frequencies.

The Panther Lake models that have the new big and very good GPU are extremely expensive and also hard to find, despite the fact that the GPU continues to be produced by TSMC. Perhaps TSMC has raised its price and prioritizes other customers, so Intel cannot get enough big GPUs, but even the Panther Lake models with the very small GPU (much smaller than Intel has used in many years for its mobile CPUs) have become far too expensive.

Because Panther Lake introduced a few important new features that could have been interesting for experiments in software development (e.g. FRED), I intended to buy some mini-PC with Panther Lake, but I gave up because even one that would cost double in comparison with the mini-PC with Arrow Lake H from last year that I have (i.e. around $1000 as barebone, instead of around $500) would be a downgrade in specs, instead of being an upgrade.

Indeed, there are very few absolute numbers that could provide useful information for comparison with alternatives.

Moreover, the excessive frequency of phrases like "landing directly on the metric that matters most" has become annoying in these AI-assisted writings.

I have also seen extremely rare cases of Linux freezes exactly like you described, and I have wondered if there can be any relationship between them and the NVIDIA drivers, mainly because they are the only closed-source drivers that I use.

Nonetheless, I have not seen any evidence about such a relationship. The freezes never occurred while the computer works alone and some program uses the GPU. In all cases the freezes happened right after some quick mouse movement.

The culprit is definitely somewhere in the device drivers, and it cannot be excluded that this may have something to do with NVIDIA, because I do not remember if I have ever seen identical freezes with AMD or Intel GPUs, but that could be just because I have spent less time using directly such computers, instead of using them remotely through SSH.

In any case, this bug is something that requires interactions with the mouse driver, perhaps also with the keyboard driver, and the X server might also have some role.

In such cases, network and HDD/SSD activities appeared to continue normally, only the display was frozen and the keyboard and mouse did not respond. While the initiator could have been something done by the X server, something was stuck in the kernel, because not even the keys that should be intercepted by the kernel worked, as you have also said.

This is certainly a bug whose cause has not be discovered for many years, but it is not yet clear whether it really has anything to do with NVIDIA, since its main effects are upon keyboard and mouse.

Even in the recent past, all the countries dominated by the Soviet Union have gone for a half of century without problems, while a supermajority of their citizens actively hated their government, and by "hate" I mean like really wishing all of them dead.

This was made possible with traditional surveillance.

With the modern surveillance means and with drones and robots, there will no longer exist any way in which even a great supermajority could remove a government.

I see no problem with every private citizen having a video camera that records everything around their home or business, and when a crime happens the police can solicit the recordings.

Also it is fine if such a private surveillance system alerts the police when a crime is in progress.

What I find completely unacceptable is to have such ubiquitous surveillance means that are networked and available to the police or other such institutions for real-time surveillance of whatever they choose. It is absolutely certain that whoever will have access to the centralized control will abuse of this power.

I have grown up in a country occupied by foreign invaders, who have installed in power a government of their choice, who have robbed and murdered whomever they wanted, and then for almost a half of century nobody could do anything against them, because everybody was under surveillance, so that no opposition could be organized.

Americans do not really understand how frustrating it is to live in this way and they fail to recognize how quickly their country becomes more and more similar to the former "communist" countries.

I doubt that there was a "german" word in Old English.

There are 2 "german" words. One refers to what were previously called Teutonic people, from the name they used themselves, which was later changed to the name used in Latin by Caesar for them.

The second "german" word, which is also spelled "germane" comes from a completely unrelated Latin word which refers to siblings who share both parents, whence "hermano" in Spanish.

The second sense "germane" seems older in English. Perhaps it already existed as a Latin borrowing in Old English.

Otherwise, perhaps the author has used "Germanstuff" because no word for Titans existed in Old English and "titanium" was discovered and named by a German, i.e. by Klaproth, from whom a lot of chemical element names have come.

The home computers like those from Commodore, Apple, Atari etc. lacked protection against memory errors, but the computers intended for business, like the IBM PC and all its clones had memory error detection capability in the form of parity.

Absolutely all IBM PC originals or clones until those with 486 and with the early Pentium variants supported parity on the motherboard.

The user could choose to not install the parity chip (or when the first memory modules appeared there were also slightly cheaper modules without the parity chip), but that was the user's decision, all the motherboards supported parity.

On IBM PC compatibles, the lack of protection against memory errors had never existed before Intel segmented the market between "non-Pro" and "Pro", by launching the Triton chipset, which no longer supported parity memory.

As long as the memory modules were byte-wide, only parity could be implemented. ECC memory could appear only later, after the passage to wide memory modules.

A steel case has too little effect on cosmic radiation, but it is good to shield electrical noise.

The computers in plastic cases can sometimes be affected by appliances with electrical motors that are used nearby them.

The cosmic radiation is attenuated only inside a big building, e.g. one with many stories above you. A really great attenuation is obtained only underground.

No, that is not true.

That link says that only the Vulkan video encode functions have been disabled, due to bugs.

Vulkan video decoding remains enabled also in the Intel GPU drivers.

It is important in the sense that many Linux programs did not bother to support both the Intel video API and the NVIDIA video API, so they work only with the Intel video API, which is also supported by AMD GPUs.

Programs that are converted to Vulkan should work with any GPUs.

VA-API works very well with the GPUs that support it, while the NVIDIA video API also works very well with the GPUs that support it, i.e. the NVIDIA GPUs.

The Vulkan video API has worked well for some time on NVIDIA, I switched my video player to it long ago.

Eventually the Vulkan video API should work well on all GPUs, so there will be a unified video API on Linux.

If the GPU is new enough to include a hardware AV1 decoder.

For NVIDIA, that means Ampere or newer (RTX 30xx or newer).

Turing or older (RTX 20xx or older) do not have support for AV1.

Vulkan has the advantage of providing a unified interface for video decoding.

Previously on Linux some programs were written to use only the Intel API or only the NVIDIA API. Fewer programs could use any of the 2 video APIs. (The AMD GPUs also supported the Intel API.)

With Vulkan, the same program should work with any GPU.

Vulkan has specific functions for different video codecs. To be able to use the hardware GPU support for AV1, the program that uses Vulkan for video decoding must also include support for AV1, i.e. it must invoke the corresponding Vulkan functions.

For now, it is not clear if Firefox already includes support for all codecs. In the initial version they could have included only partial Vulkan support, for instance only for H.264 video decoding, with the intention to add complete Vulkan support in some future version.

I have heard frequently complaints about NVIDIA drivers on Linux, but I always wonder about which are the exact circumstances in which such problems can appear.

I have used NVIDIA GPUs on Linux continuously since 2005, i.e. for 21 years.

During this time I have been using more than a dozen different kinds of desktop NVIDIA GPUs, both GeForce and Quadro (I have multiple computers). I have also used several kinds of laptops with NVIDIA GPUs, both GeForce and Quadro, from Dell and from Lenovo. I have also used NVIDIA Jetson SBCs, with NVIDIA Volta GPUs.

On all these many kinds of hardware and during these 21 years, I have never had any problem with the NVIDIA GPUs, either on Linux or on FreeBSD (NVIDIA is among the few hardware vendors who also provide FreeBSD device drivers).

On the other hand, I have had various problems with my AMD GPUs, or, more rarely, with my Intel GPUs (OpenGL defects on both, while with certain AMD GPUs I had problems in multiple monitor configurations).

Today I have more AMD GPUs than NVIDIA GPUs, but that is because I use the AMD GPUs for computational purposes, while the NVIDIA GPUs are used for graphics.

I use many programs based on OpenGL, and the quality of the graphics has always been perfect with NVIDIA GPUs, while in the past it was quite bad on both AMD GPUs and Intel GPUs, regardless whether the "professional" closed-source AMD drivers were used, or their open-source drivers. By bad I mean that the AMD and Intel GPUs failed to render correctly some complex images drawn with OpenGL, unlike the NVIDIA GPUs, which were flawless. The quality of the AMD and Intel drivers has improved a lot in recent years, but I have not checked whether now they really match the NVIDIA drivers in all cases.

While the above was about OpenGL, where there has never been any doubt that the NVIDIA device drivers are the best, regarding video, there is more than a decade since I have never used any monitors that are not 4k resolution, 10-bit per color component and P3-D65 (Display P3) wide color gamut. I frequently watch various high-resolution movies, using various kinds of video codecs on an NVIDIA GPU and the quality of rendering has always been impeccable. Though unlike with OpenGL, with video I also do not remember ever having any problem on Intel GPUs.

I do not doubt that there must be cases when NVIDIA does not work well on Linux, but I am certain that those are never caused by the NVIDIA drivers alone, but by some interaction with other installed software that may have been written to work only with other GPUs.

For example, even if some years ago Firefox had worked with my NVIDIA GPU, that got broken at some point and for the last few years Firefox claims to not detect any GPU, so WebGL and hardware video decoding do not work, and all efforts to force their enabling in the Firefox configuration have failed, even if other browsers like Chromium and Vivaldi work perfectly and a great number of other graphics or video programs also work perfectly. Firefox is the only program that I have ever used and that has not worked fine with NVIDIA GPUs.

I certainly assign this bug to Firefox, not to the NVIDIA drivers, which also work perfectly with the programs that I write myself.

Among the Linux kernel developers, there are some who for some weird reason have sabotaged the NVIDIA drivers from time to time for many years, by making various gratuitous changes in the Linux kernel API for device drivers, designed with the precise purpose of breaking the existing NVIDIA drivers.

Every time when this happens, the NVIDIA drivers fail to work with the new Linux kernel version, but that is no fault of NVIDIA. This creates an additional work for the NVIDIA maintainers, who must release a new version of the NVIDIA device drivers, as soon as they succeed to design a workaround for the Linux API changes. The workaround may be difficult, because in many cases the Linux kernel has stopped exporting certain functions used by the NVIDIA driver, restricting their use to device drivers with different code licenses. This export conditioned by the license of the driver that imports it has no legal basis and no relationship whatsoever with the requirements of the GPL.

This is the reason why some people claim that they could not boot some Linux system with certain NVIDIA drivers. I also assign this fault to the Linux kernel developers who had intentionally broken the NVIDIA device drivers, which I consider a childish and unprofessional behavior. There is no doubt that NVIDIA cannot be criticized when this happens.

To be clear, I consider that it is extremely bad and undesirable to run on your computer any privileged code, e.g. a device driver, which is not open source.

However, this policy should not be something that kernel developers enforce by artificial restrictions. They should try to educate their users to avoid unsafe closed source device drivers, but when a user has serious practical reasons to make an exception, that should be the user's decision, and it is not the role of a kernel maintainer to forbid this.

These are very well formulated rules about how to use an LLM to write documentation.

Writing is thinking. Spending time on the writing process — on deciding what to emphasize and how to structure your ideas clearly — teaches you more about your topic. If you circumvent this process, you will probably walk away with a poorer understanding of the subject matter.

This is a point with which I completely agree.

It is extremely frequent that only when you write a detailed documentation for the product that you have designed, you finally understand some of its finer points, which perhaps need some last-minute changes, to prevent future problems.

Because of this, I despise the companies where the project plans do not allocate an adequate time for writing documentation, believing that this is some kind of unproductive activity. I have worked at many companies, in many countries, and without exception the best productivity, measured in the rate of completing projects that worked OK in production or at customers, was at the companies where the project schedules seemed to be more relaxed, by allocating a generous time for writing documentation.

Also when I was a child, much of what I did learn I learned by trying to explain those things to my schoolmates, and this was significantly more than I had learned directly from teachers.

What is interesting here is that this is an optimization study, whose goal was to determine the optimum implementation variant for matrix multiplication on a Zen 3 CPU.

It is likely that a similar optimization strategy would work for a modern Zen 5, though some of the parameters for the optimum variant would probably have double values, because Zen 5 has twice more registers, each double in size, and it can process and transfer a double number of FP32 per clock cycle.

The value given by the author of 63.5% of the theoretical maximum throughput, is likely to be pessimistic, because when doing heavy computations the clock frequency of the CPU will drop, so the actual efficiency might be higher, e.g. perhaps of 70% to 80% of the theoretical maximum throughput at that clock frequency.

The ATLAS BLAS-compatible library attempted to perform automatically such an optimization for its host computer, but I have not studied it to see whether its optimization methods would still work on modern CPUs with AVX+FMA or with AVX-512.

The throughput quoted here is for a single core, and it is not reported any attempt to measure how well this scales to all cores.

A modern Zen 5 should reach a throughput more than twice this value per core, with a total over 3 TFLOP/s for the complete CPU.

That 100 TFLOP/s for FP32 is for a GPU that might cost from 30 to 100 times more than a desktop CPU, so it is not certain that its performance per dollar is any better than for the desktop CPU.

This is very different from 7 to 10 years ago, when GPUs had a far higher performance per dollar than any CPUs. Since then, the performance per dollar of the desktop CPUs has increased, mainly because their prices have not increased much, while the performance per dollar of the GPUs has decreased, mainly because of a great increase in their prices, especially for the "datacenter" GPUs, which now may be more than 10 times more expensive than they were 7 years ago.

I have seen a lot of complaints about LED lamps with a short life, usually caused by defects in their integrated power supplies, typically arising from bad cooling.

On the other hand, I have more than a dozen LED lamps that have been continuously used for more than ten years and none of them has failed yet. They are mounted in classic Edison fixtures for incandescent lamps and they were made by Philips, but at the time when they were bought they were one of their better models, and having a 4000 K color temperature, i.e. very slightly yellowish, but not noticeably yellow, like the lamps with a color temperature less than 3000 K, which try to imitate incandescent lamps.

The sodium lamps that were ubiquitous for outdoor lighting before LEDs were quite good from this point of view.

Amber LEDs could provide a similar experience.

While what can be done with less bits per parameter may be interesting, this is not really the important number for an LLM.

Much more important is the total amount of memory needed by an LLM, which can be decreased either by reducing the number of bits per parameter or the number of parameters. Arithmetic circuits are already cheap so for the inference cost the amount of memory transfers is more important.

It is not clear yet which number of bits per parameter allows the minimization of the total memory requirement, at a given LLM quality.

Cosmic radiation is always a source of errors for any kind of DRAM.

Whether it is the primary source of errors, depends on the design of the DRAM die.

In a badly designed DRAM there could be many other error causes.

The designers of a DRAM certainly attempt to minimize all the error causes that they can control. If they succeed, the cosmic radiation would remain the primary error source.

Without access to internal documents of the DRAM vendors, we cannot know if they have indeed minimized all other error causes.

In modern DRAM chips, a major error cause can also be the disturbance of some memory cells when some other cells are accessed in their neighborhood, which is the basis of the Rowhammer attacks, but which can also happen during the normal use of the memory, when certain access patterns happen by chance.

The DRAM vendors do not provide details about the behavior of their devices, with the hope that this makes harder the task for someone who wants to design a variant of the Rowhammer attacks, but this also makes impossible for the owner of the memory to predict whether an application program will not perform by chance an access pattern that will unintentionally flip some memory bits, which without ECC will not be detected and corrected.

If you do not monitor it continuously, you achieve nothing, because the memory errors happen seldom and unpredictably.

Without ECC, you need a custom operating system, which will compute some error detection code, e.g. a CRC, for each read-only memory page, i.e. including all code pages and constant pages, and all cached but not dirty file system pages, and which will check the CRC codes periodically in the background.

That would still leave the read-write data segments unprotected, though on those some errors may be benign, if the locations are overwritten later without being read again.

Some years ago, it was easy to find ECC modules with a so small price difference.

From that time, I have a few old computers with 64 GB or 128 GB of DDR4 ECC memory.

Unfortunately, after the passage to DDR5, DDR5 ECC UDIMMs have become hard to find, and even when you could find them, the price difference could be as high as 30% to 50%.

Both AMD and Intel publish on their site, for each CPU model, the maximum supported memory speed.

If the CPU does not work at that speed, you are entitled to a replacement or a refund.

For instance, AMD Ryzen™ 9 9950X3D is guaranteed to work with DDR5-5600, but with nothing faster. No AMD non-server CPU goes above this limit for DDR5.

Some of the Intel CPUs are guaranteed to work with faster memories, e.g. Core Ultra 9 285K with up to DDR5-6400, and the very recently launched Core Ultra 7 270K PLUS with up to DDR5-7200.

Correct.

There is a lot of direct evidence from increased error rates in computers on airplanes.

Also from the recent Kimi models it seems that it was difficult to remove the censorship.

But in both cases, eventually uncensored variants were published, even if it took more time than for other models.

Yes, but it is easy to find and download many Qwen3.6 variants from which the censorship has been removed.

This is one of the advantages of being an open weights model.

You can find on Huggingface a huge number of Chinese open weights LLMs from which the censorship has been removed.

They typically contain in their names words like -abliterated or -uncensored.

For some of the recent bigger Chinese LLMs, it took a longer time until someone succeeded to remove the censorship, but eventually uncensored variants were published.

E.g. for Kimi 2.6 an uncensored variant appeared only a couple weeks ago.

Yes, while the Chrome/Chromium hardware decoding, or any other uses of the GPU, like WebGL, was always impeccable on Linux, with Firefox that was always an adventure, much more often not working than working (at least with an NVIDIA GPU).

So I also hope that Vulkan decoding might solve this behavior of Firefox on Linux.