I agree. In the past, I have successfully used Debian and Alpine for embedded. Never needed to compile OS kernels or standard DLLs, other people already did and published in these package repositories.
As a part of the user-mode half of the GPU driver, GPU vendors ship media foundation transform DLLs to use HEVC hardware codecs. Don’t AMD, Intel and nVidia already pay patent royalties? I expect them to include into price of the GPUs with hardware support i.e. all of them made in the last decade.
Yes, albeit 100ppm is bad/cheap crystals. 50-30ppm is normal.
The difference with a quartz watch is that it's factory calibrated with the load capacitance on the crystal, and that it's a 32768Hz tuning fork. For a variety of reasons, generating higher frequency clocks off 32768Hz is... "annoying" (huge PLL ratio, very slow feedback loop step), and typical crystals in the 10-100MHz range are just less precise and thermally stable. (Not sure why, I'm not an oscillator manufacturer...)
(NB: you can of course correct for initial deviation in software. The actual problem is stability over temperature.)
> benefits from being kept at constant-ish body temperature
Some people take off their watches every day before going to sleep.
These high-end quartz oscillators are probably too expensive to use in commodity computers. Still, the cost shouldn’t look too bad when compared to a price or an airplane, marine vessel, or most military equipment.
We're in agreement; 1ppm is 31.5s/yr so this lines up with OCXO performance / keeping the crystal at constant temperature. It's still 1km zone of spoofability per hour without resync.
I'm unaware of any technology between OCXOs and Rb standards. The latter have gotten smaller but not tiny and also need quite a bit of ongoing maintenance and calibration.
> On which image does the gradation appear more even? It’s the second one!
Can’t reproduce. Tested on two monitors on my desk, designer-targeted Benq and cheap laptop. On the Benq, darkest 3 segments are indistinguishable, the 4-th one barely distinguishable. On the laptop, darkest 4 segments are indistinguishable, the 5-th barely distinguishable. However, on the “emitted light intensity” all bars are clearly visible.
> Image resizing
“Unsurprisingly, C gives the correct result” On my computers B very similar to A, just a tiny bit darker. While the “correct” C result is a lot lighter than A.
Also from the same section:
> B the result of resizing the pattern by 50% directly in sRGB-space (using bicubic interpolation)
Bicubic interpolation is only applicable when enraging images; downsampling is very different problem from interpolation.
“Is it because of government regulations, do we need to deregulate?”
Insufficient law enforcement. The same memory manufacturers already broke antimonopoly laws in the past, pleaded guilty. Apparently the fines were too small for these companies to care, and the people responsible were promoted instead of being punished. More information: https://en.wikipedia.org/wiki/DRAM_price_fixing_scandal
Might be jurisdiction. Let’s say a person who is not a Polish citizen committing and broadcasting a crime outside of Poland, then trying to enter Poland. IANAL but I think this law sends that person to jail as long as the video is accessible from inside Poland.
Not anymore. On modern hardware, the only operation where integers win is single cycle add/sub. For the rest of operations (multiplication, division, square roots, etc.) floating point is faster, sometimes by a lot.
On modern processors, floating point addition often has equal performance to floating point multiplication. For example, on AMD Zen4 it’s 3 cycles latency and 0.5 cycles throughput.
I’m not sure that trick going to work in the context of computer graphics. To transform vectors or multiply matrices you need a mix of multiplications and additions, or an equivalent sequence of FMAs.
Good article. Worth noting C# standard library handles most of that complexity, no regular expressions required. Call System.Net.Mail.MailAddress.TryCreate, if successful read Address property to find the normalised address.
Cool trick, but personally I don’t trust C bitfields. When I need something like that, I usually create C++ class or C# structure with a single private uint64 field, and public methods to extract or manipulate the logical fields.
Because the class/structure only has a single uint64 field, the compilers are likely to pass value in a single general-purpose register. I believe that’s unlikely to happen for a structure with bit fields.
If you target AVX2 or newer you also have BMI1 and BMI2, intrinsics like bextr and bzhi are probably faster than whatever codes compilers are generating for bit fields.
Binary compatibility of bit fields is a moot point, using them at the API surface across compilers or languages is not ideal. A structure with a single uint64 field is very compatible.
None so far. When I try to use these language models in the primary areas of my expertise like SIMD or GPGPU they fail to do any good. When I ask them to implement some general-purpose stuff, the output is too low quality to be useful in my software.
Still, find them incredibly useful for code review (despite unable to write good C++ or C#, smart enough to detect issues there), also dealing with technologies outside of my area of expertise like Python or web stuff.
