janwas

3 ms·

1.
by janwas 9d ago
VQSort users include numpy, XLA (for sparse tensors), ScaNN: https://sourcegraph.com/search?q=context:global+hwy/contrib/...
2.
by janwas 9d ago
(Co-)author here :) I'd absolutely still use Highway, and do. My experience is that even two separate implementations diverge over time and I'd have low confidence in bringing the same updates and improvements to all, even with LL
3.
by janwas 10d ago
As posted here: https://news.ycombinator.com/item?id=49693906 several years ago, using 6 threads and vectorized C++, we saw about 240-270 MP/s decode speed. Hence this should be possible in < 100ms. Not sure how the
4.
by janwas 10d ago
> This tells me you don't know how codecs work Laughable. My conservative estimate is that a few-MP image with all but a smallish region encoded using skip blocks will spend a few KiB on that. This is very expensive compared to send
5.
by janwas 11d ago
Not at all. CPU power is proportional to frequency^2. Running on 4-6 little/efficiency cores (which are widespread on mobile) is likely faster than one big core, and uses less energy.
6.
by janwas 11d ago
There is indeed an issue with the JPEG format that makes parallelization difficult: the lack of a 'table of contents' with offsets to tiles. Various workarounds (for example RST markers or self-sychronizing properties of Huffman)
7.
by janwas 11d ago
I note you made no response to the objection about representing a temporal sequence with a single, nonrepresentative and cherry-picked, screenshot. As to bad experience, that seems like a legit personal preference, but disturbingly un-nuanc
8.
by janwas 11d ago
Ah, an accusation of misquoting. I actually quoted your exact words minus "is" and "it supports". I think we disagree on the degree of flexibility, for sure. A cap on layers (under user/browser) absolutely makes sen
9.
by janwas 11d ago
We can agree on wanting a better internet :) I participated in the design of those filters, so no, I do not deeply dislike the way they look. This gaslighting is not convincing. No matter how many filters AVIF has, I distinctly remember til
10.
by janwas 12d ago
Surprised and disappointed to hear "bad-faith reading". I have seen AVIF tiling artifacts myself. Hand-waving them away by appealing to a metric that averages across all image pixels is not convincing.
11.
by janwas 12d ago
Sounds like some strong assumptions here, particularly a stable and non-metered connection. Imagine fast scroll across an image gallery on a slow connection (including cell handovers). Or range requests, where a service worker only download
12.
by janwas 12d ago
I find it misleading to call AVIF's "up to four passes" "very flexible". It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions
13.
by janwas 12d ago
+1, this is super unfair to show the one point in time where AVIF progressive looks better - right after it receives its 'preview' (which as you say is 4x as big as JPEG XL's). I value integrity, especially when communicating
14.
by janwas 12d ago
Something is fishy here. The JPEG XL report [1] measured between 240-270 Megapixels/s on 6 cores using the C++ implementation (disclosure: I was responsible for its SIMD/threading), about twice as fast as the then-current libaom.
15.
by janwas 1mo ago
Great writeup, especially liked the line by line explanation :) We actually did manage to get dynamic dispatch working in Compiler explorer with Matt's help: https://gcc.godbolt.org/z/KM3ben7ET Maybe interesting
16.
by janwas 1mo ago
Not seeing this at all. We routinely and easily target SSE4, AVX2, AVX-512 (in four variants) using the same application code in one binary. Frankly, this seems better to me than four separate RISC-V matmul extensions.
17.
by janwas 1mo ago
The future is already partially here: see the recent "do we still need gpus" article.
18.
by janwas 1mo ago
Not sure what this comment is based on. Arm introduced a scalable SIMD whose whole point is to be expandable. AVX-512 works very well, for example on Zen 4 and 5.
19.
by janwas 2mo ago
That is not at all my experience :) Please expand on what "vertically-oriented scope" means.
20.
by janwas 2mo ago
If you are running on large-scale data, have you validated at that scale (comparing results)? From a quick look at the code, it looks like there is a 42-bit hash (computed via single-mul hash function) which can have collisions and thus ret
21.
by janwas 2mo ago
hm, maybe not so trivially correct here. Do I understand correctly that incorrect results can happen as a result of a 42-bit hash collision? That could happen after less than one MB of input, given the simple one-mul hash. BTW throughput is
22.
by janwas 4mo ago
Author/Highway TL here. Happy to discuss.
23.
by janwas 4mo ago
Impressive result. Congrats!
24.
by janwas 4mo ago
Oops, the final T got cut off somehow, sorry about that. https://gcc.godbolt.org/z/KM3ben7ET
25.
by janwas 4mo ago
Any suggestions for improvement? We went through >5 iterations of the dispatching and I am fairly confident this is about as good as it gets in current C++. I suppose "macro hell" is a matter of taste. Objectively, we have six
26.
by janwas 4mo ago
Working on one together with fastcode.org :)
27.
by janwas 4mo ago
To be clear, "better abstractions" here seems to mean macros for assembly language. To each their own. What bothers me is advocating for this, or denigrating more generally useful alternatives, without mentioning the very narrow n
28.
by janwas 4mo ago
Correction (typo): Z13 lacks fp32.
29.
by janwas 4mo ago
Oh, interesting :) I meant Fastcode.org.
30.
by janwas 4mo ago
Is this a good faith reply? The particular abstraction we built, and is being discussed, is manifestly and obviously not a lowest common denominator. Looks like you are deploying a second straw man, that of zero cost. In other comments here

More ›