dr_zoidberg

> Additionally, 512-bit wide vectors are just too big - the resulting vector units take up too much die space even on big cores, and the power consumption causes issues causing said dies to downclock.

This is no longer true, citing [0]:

> At least, it means we need to adjust our mental model of the frequency related cost of AVX-512 instructions. Rather than the prior-generation verdict of “AVX-512 generally causes significant downclocking”, on these Ice Lake and Rocket Lake client chips we can say that AVX-512 causes insignificant (usually, none at all) license-based downclocking and I expect this to be true on other ICL and RKL client chips as well.

And we still have to see AMDs implementation of AVX512 on Zen4 to know what behavior and limits it may have (if any).

[0] https://travisdowns.github.io/blog/2020/08/19/icl-avx512-fre...

The subtitle for the talk is "a security focused introduction to eBPF". I guess they changed it to give a bit of a heads-up for those just reading the posts title, but it's not the subtitle chosen by the author.

Deep Learning with Python (2nd ed), by Francois Chollet.

If you don't mind about learning the part where you program, it's got a lot of beginner/intermediate concepts clearly explained. If you do dive into the programming examples, you get to play around with a few architectures and ideas and you're left on the step to dive into the more advanced material knowing what you're doing.

Yes, but it stems from the fact that some phone manufacturers decided to reuse the hardware IP they already had in place for JPEG compression instead of paying for another chip that could do MPEG. It works, but it's not compression.

Then for some weird reason it gained traction as a "good quality video codec" (probably because there's no motion vectors, hence the associated artifacts simply can't happen with it).

Chiming in for HiDPI displays, I have a global 125% scale, so I had to zoom out the browser to 80% to get 1:1 on the rendered images.

I keep a few projects at work where we train models with Keras+TensorFlow. Twice before I tried to switch to PyTorch, because it did have nicer features/syntax for research and SOTA models, but deploy and support was limited on the toolchain we use, so we had to stay with Keras+TF. I'd still like to switch to PyTorch because of a few goodies, but the deploy of the models on some platforms is still simpler starting from a TF model.

If anyone has a few links or resources to point me to, I'm more than happy to make a third try.

Yes, and Sony has been really impressive with their cameras lately. It looks like finally Canon and Nikon woke up and start trying to match their (unfortunately for me, Olympus decided to sell their camera business? Did somebody buy them yet?).

The thing about larger sensors, for those that aren't aware, is that they produce much better quality images because each pixel is larger, and can gather more light. More light equals a stronger signal, in a noisy ambient.

I sometimes try astrophotography because it lets me combine my photography hobby with my programming passion, and I end up writing my own processing pipelines. With a compact camera, I could get the ghost of one of the brightest galaxies in the sky (Centaurus A in the southern hemisphere). With the MFT camera, using the included kit lens I got a little bit of detail, but it was just a few pixels wide. Switch on to a vintage lens I got for ~15 dollars, and I managed to get the galaxy and quite some detail. Not the same as a telescope image, but very impressive for a 1970's lens on a small camera!

And the noise levels aren't even comparable. My old compact camera was Noisy with a capital N. Of course I didn't realize it when I bought it, but it was[0]. I see the same on phone cameras (the sensors are about the same size now). The MFT even on ISO 25600 (highest it goes to) isn't as noisy as the compact camera was at 3200.

Most phones will cover that with a lot of computation, and that's fine for a small screen. But load your pictures on a large monitor and you'll start seeing the details and differences. However (and it has been said everywhere in the comments) phones are usually way more convenient because you always have it with you.

[0] For reference, some 12 years ago I bought a Canon G12, then a G16, and then moved on to a Olympus OMD E10. On every change I got far better quality at about the same camera size, though the olympus is slightly more bulky, and you have to factor in the lens too.

Compact cameras (under $500) usually have great macro lenses too, though you miss the flexibility of being able to change the lens. I've owned for quite a while a Micro Four Thirds camera from Olympus and that's a very good spot to be a hobbyist: not too expensive, but can do "pro things" like changing lenses, shoots raw, has a horseshoe socket, etc. Of course, the quality is not the same as a full frame camera, but then again, I'm not a pro :)

From my experience with deep learning I can eyeball it: one or two orders of magnitude. The fine details may be different on this particular problem.

In DL in general, if you have sort of equivalent CPU/GPUs (think a 5600 vs GeForce 3070) you'll find yourself in the range of 10 to 30x faster training with GPU. If you have substantially different platforms, you can start looking at 100x speedups or more.

For example, my mobile 4600H CPU trains about 100x slower than a desktop GeForce 2060. And close to 300x faster than the old Intel 7200u I use as a "slow system" to test things. Which also has a GeForce 940MX, that trains about 30x slower than the 2060 (if you manage to make your model small enough to fit in 2GB of VRAM).

Not just on this project, but I've seen a few more not moving past 3.8 for support and I don't quite get why that's been happening. Did something happen on 3.9 or later that didn't caught my eye?

I was going to mention this: on 2019 I started a niche channel, through some good timed posts on reddit I gathered traction, and then my own interest in the channel waned. I still have ~400 subscribers (it stayed at about the all-time high level) and the channel is still gathering about 100 views a month on content that is 2-years old for the newest.

I'm not sure "The Algorithm" is really such a beast as it's portrayed, and some of these takes seem like reductionist views on something that is complex to understand. Two other important metrics that YT checks on videos are watch time and watch %. If those are high, they know the content is good for recommending, even if it's sporadic.

And yes, I also follow channels who post content on a per-week/fortnight/monthly basis and they do fine.

We've seen over the past 2 years that people really want to stick to their habits, no matter what. So I'm not against suggesting a _slight change_ in habits. Even something like changing cow meat for other types of meat (lamb, pig, chicken) has a big effect on carbon footprint, and people who want to eat meat still get to eat meat -- just another kind of.

On camera phones the random movements come from the users own instability when taking pictures.

It's also a status symbol, and as such they're bought not because of their intrinsic value.

There are countries were earning 12k USD a year puts you in the top 1%. Just to give you some context.

Can't you host an errata somewhere that explains the changes and how it fixes the thesis?

For those surprised at the dot product benchmark on 3.1 [0] where np.dot() is substantially faster when using floats over ints, the things is simply that numpy can use BLAS libraries for floats, but not for ints (because BLAS libs don't implement integer data types).

[0] https://tvm.d2l.ai/chapter_cpu_schedules/arch.html

[1] https://stackoverflow.com/questions/11856293/numpy-dot-produ...

They tried it for home desktop ~10 years ago and had to back down: https://en.wikipedia.org/wiki/Intel_Upgrade_Service

Second this. A few years back I wrote a chapter for a book and then the editor screwed up. With one of the other authors, we took on editing and fixing things around.

As I had seen so many versions of it, my chapter was the one on which I could do the less editing around -- I was absolutely tired of it. Lo a behold, the book gets published, I get a physical copy on my hands, and I start seeing typos and small mistakes around. Nothing too serious, but things that I would've fixed.

I know those mistakes are there. Only a handful of people have pointed them out. Those people have not only read the book, the followed it and questioned it. It's nice to be reached out, even if I already know what's wrong.

> ...but punters walking around a computer store are not going to appreciate the differences if Intel get away with making big claims on the sticker (possibly even spinning "software defined silicon" as a way for them to upgrade hardware over the wire) - for the average consumer this would making an already difficult to achieve informed comparisons hopeless.

This. I can already imagine it: "hey, my notebook was getting a bit sluggish, but I upgraded it over the internet with Software Defined Silicon(TM) and just spent $100 instead of $500 that a new one would've costed".

And everyone who knows the "extra" capabilities were already there to begin with would be screaming on the inside.

DFT as in Density Functional Theory, not the Discrete Fourier Transform. Yes, in the context of the article (quantum physics) it may not need clarification, but to some of us having the acronym expanded helps.

I got a weird feeling from the article in which the author seems to know quite a bit about numpy (citing a few parts of the source even!) but then it uses python loops all around!

Just like you, I'm not really following the domain calculations, so maybe there's a reason that code can't be properly vectorized. But as others have commented, I'm a bit at a loss why the author didn't try numba or Cython.

I think that part of why the tokenization is a proble for math here is that it doesn't seem to be carrying overflow into the left token. Anyway, I haven't worked with GPT in detail to do a deeper analysis than that hunch, so take my comment with a couple of salt grains.

> Fun fact: the game looks like that because it has no textures. Instead, every polygon is colored individually. Through a recent update did give the terrain textures. Aircraft still don't have them.

Of course that description made me think of Red Baron[0].

[0] https://en.wikipedia.org/wiki/Red_Baron_(1990_video_game)

You're missing Microsoft: MANAMA

Yes, I did confused the part about Keccak[0] being "slow" to compute without specfic hardware/extensions with it being slow on GPUs as a design goal.

[0] Taking this as an example of newer crpytographic hashes, rather than the "old ones" that were easier/faster to calculate on GPUs.

I must have conflated Keccak's "slow without specific hardware/extensions" with "slow on purpose against GPUs". Both are similar (why would a GPU have an operation for cryptography?) but obviously not the same thing.

> (fast in hardware, fast in software, fast in SIMD, whatever)

"Slow to compute in GPUs" has been another design criterion for a while. It helps against brute force attacks. Of course, you might want your hash to be fast on GPUs too, if you're trying to accelerate something, bu cryptographic hashes usually aim for attack resistance.

1GB is huge for PyPI. In this kind of situations, is there a good way to provide a PyPI install while providing a secondary channel to download the massive assests? Say that I was distributing a project that relies on a few large binaries, and still want it to be pip-installable, what would be the best way to do that?

I remember headlines saying that, but the most I'm finding is that the paper that claimed such links was quickly retracted from bioRxiv[0]. I'm a bit lost as to how misinformation played in placing a Nobel Prize winner in the mix, possibly they mentioned there was research suggesting that link.

[0] https://www.statnews.com/2020/02/03/retraction-faulty-corona...