Bulat_Ziganshin

No, but LPDDR means soldered, there are no LPDDR dimms

They didn't say that Mediatek made the cpu sores. Grace is NVidia's own cpu arm cores. I bet that Mediatek made other parts of SoC necessary for a notebook

I think that Nvidia made GPU and CPU, and Mediatek made other parts of SoC necessary for a notebook. Grace is Nvidia's own CPU ARM core

They compare HGEMM implementations. At least CUBLAS has HGEMM functions.

HGEMM means half-precision (i.e. FP16) general matrix multiplication

just to make you even more paranoid - zen2/4 (and probably e-cores and zen5) can rename memory operands too (you start to do strange things when Intel limits you to 16 registers)!

so today it needs to go through SSD or maybe the network LOL. but for real conspiracy, we should use paper and pencil

what about 8-bit ANDN? SHL essentially uses CL, so it may be because 8-bit subregister of "constant register" isn't present on the bypass network

I once searched github for simd libraries, sorted by popularity, and added most popular of them to my list: https://github.com/stars/Bulat-Ziganshin/lists/simd

indeed, highway is the popularity leader, it implements lots of SIMD operations and supports lots of hardware including SVE/RVV with runtime SIMD width, although IMHO it has a bit longer learning curve

with m/t, the algorithm is memory-bound, so the performance should be determined strictly by the memory throughput

JOIN SQL operation is another usecase

it's how Google managed to convince young people all over the world to start reading those crappy A&DS books

Intel shifts anyway mask out higher bits of CL, this hurts sometimes e.g. when you need to shift by 1..64 bits

high-performance sorting algos do either merging or partitioning. I.e., you merge R input streams into one, or split one input stream into R (for quick, radix and sample sort).

1. For merge sort of N elements, you have to perform log(N)/log(R) passes

2. For sample sort - C*log(N)/log(R), where С depends on the distribution of your data, there are no strict guarantees

3. For radix sort of K-byte elements exactly K passes (indeed, 256 ways is optimal according to my tests), which is usually larger than the previous value

While Mergesort looks preferable since it uses the least and fixed amount of passes, the merging code itself is less efficient - there are not much independent CPU operations, making it slower than samplesort and especially radix sort for small inputs.

So, it seems that the best strategy combines two different levels - for larger blocks you absolutely need to minimize the amount of passes [over memory] and employ multithreading, while for smaller blocks we need to minimize the amount of CPU operations and increase ILP.

Today two well-recognized algos are IPS4O for larger blocks and Google's SIMD QuickSort for smaller ones.

higher throughput means we can serve more people, not that anyone will be served faster. it's like a multi-lane highway

because THIS code becomes faster once RCX is saved and restored during the interrupt call

we set CX only once and then use it 10000 times. the problem is not the slow calculation of CX per se, but the slow shift once we got CX from the renamer

add3 operation will have 3 inputs, though. do we have other integer operations with 3 64-bit inputs?

except that we need max() here :)

maybe, the bypass network doesn't include these "constant registers"? a bit like zen5 where some 1-cycle SIMD ops are executed in 2 cycles, probably for shortcomings of the same network

afaik, 7-zip filters can't have multiple inputs (at the encoding stage).

multiple outputs are necessary for filters that output multiple independent data streams such as bcj2. and they are equally useful for archivers and compressors.

(I'm author of freearc, another archiver software, and multiple compression algos)

PS: thank you for format comparison, it would be great to put xz format description onto its Wikipedia page. I already used you description to understand why attackers added 8 "random" bytes to one of their scripts - probably to "fix" crc-64 value.

only in indirect way - simpler format could allow to find another real maintainer *or even continue to maintain it himself), because it has less features.

but I think xz won the linux-lzma-archive formats war exactly because it was more complex than lzip, e.g. by supporting more versatile lzma2 format, which allowed to implement multi-threaded compression and decompression (pretty sophisticated things), and better crc64/sha256 hash checking

the installation process itself executes xz scripts which can make any (?) modifications to the system

1. both lzip and xz are using lzma compression library internally, so there is no difference in their compression ratio/speed

2. lzma compression is LZ + markov chains, while zstd is LZ + order-0 entropy coder (similar to zlib, rar and many other popular algorithms)

markov chains are higher-order entropy coding, i.e. one using context of previous data. it's slower, but sometimes gives better compression. but text files don't get any benefit from it. OTOH, various binary formats, like executables or databases, get significantly better compression ratio. in my tests lzma-compressed binary files are ~~10% smaller on average.

so, many claims that zstd and lzma provides the same compression ratio, are based on testing on text or other files that don't benefit from higher-order entropy coding. of course, I imply maximum-compression setting and equal dictionary size, in order to make fair comparison of compression formats rather than particular implementations.

(I'm author of freearc and several LZ-based compressors, so more or less expert in this area :)

even worse, I have Punto switcher that automatically switches language when I start typing. With default config, it changes latin c to russian one because russian language includes word "c" while it's non-sense in English.

and since it's the only Cyrillic character that's placed on the same key as the same-looking english character, I don't even see the problem with my eyes when the autoreplacement fires

my understanding is that any Debian/RPM-based Linux running sshd would become vulnerable in a year or two. The best equivalent of this exploit is the One Ring.

So the really strange thing is why they put so little effort into making this undetectable. All they needed was to make it use less time to check each login attempt.

Collin worked on XZ and its predecessor ~15 years. It seems that he did that for free, at least in recent times. Anyone will lose motivation to work for free over this period of time.

At the same time, XZ became a cornerstone of major Linxus distributions, being systemd dependency and loaded, in particular, as part of sshd. What could go wrong?

In hindsight, the commercial idea of Red Hat, utilizing the free work of thousands of developers working "just for fun", turned out to be not so brilliant.

the motivation is probably "get foot in the door". the attacker also made a few documentation-only PRs in various repos, but having code PR will make him more creditable, and also would help to add more backdoors to libarchive in the future

and librachive is now part of Windows 10, being used as a universal archive decompression library in the Explorer

many people are patriots of their countries. if state agency would approach them proposing to have paid OSS work and help their country to fight terrorism/dictatorships/capitalists/whatever-they-believe, they will feel like killing two birds with one job

if I got it right, the attack uses glibc IFUNC mechanism to patch sshd (and only sshd) to directly run some code in liblzma when sshd verifies logins.

so the problem is IFUNC mechanism, which has its valid uses but can be EASILY misused for any sort of attacks

because in order to put backdoor into xz executable, you need to infect its sources. and in order to infect the sources, you need to use a similar technique to hide the modification

i think it's American trauma. outside of the Western hemisphere, sexist and racist jokes are just jokes