Hacker Newsnew | past | comments | ask | show | jobs | submit | adgjlsfhk1's commentslogin

Compilers are only as good as the semantics you give them. C and C++ both have some pretty bad semantics in many places that heavily encourage inefficient coding patterns.

Many of the libc functions are bad apis with traditionally bad implementations.

well half of the problem is that it ended up 2 years late.

You also gain some utility. Infinite torque at idle, cheaper 4wd, better traction control, fewer mechanical problems, etc.

They tow way better aside from reduced range. And the near perfect 50/50 weight distribution means they handle better than a truck should.

it's a few hundred bucks, an extra thing to remember, takes up bed space, requires bringing gas, and is loud and annoying to use. It's not the biggest thing, but it's a pretty nice value add.

I mean, if you bought a Cybertruck, you've already given up on a ton of bed space. I'm not saying that a built-in power source isn't nice, but I doubt it swayed any minds.

LLVM doesn't fully utilize all the power, but it does use an increasing amount every year. Flang and Rust have both given LLVM plenty of example code and a fair number of contributors who want to make LLVM work better for them.

Yes. Specifically since Rust's design prevents shared mutablity, if you have 2 mutable data-structures you know that they don't alias which makes auto vectorization a whole lot easier.

Progressive decoding isn't a very useful video feature because you need to decode the whole frame before you decode the next frame for inter-frame coding methods anyway.

It is, however, a very useful image format feature, giving you most information from the spinner/sticker/emoji/sprite, and refinig the already playing loop as it loads. That's why animated jxl is a bad video format — it's not a video format, it is a separate kind of seemingly weird thing.

sounds like you were just doing the math for too much capacity. there's no rule that you have to cover your roof

Too little capacity and it takes 50 years to absorb the fixed costs.

The part I'm more excited for is all the image-like/bundle of image like data that until Jpeg-xl didn't have any good codecs (usually implemented as folders of images). One clear example of this is PBR in blender and friends. (e.g. a combo of normal map, roughness, color, metalness etc)

This is new to me. Can you elaborate please? Perhaps a link to somewhere showcasing this (and contrasting this to other solutions).

See https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-for.... TLDR is that one of the really interesting things JPEG-XL adds is the ability to have an arbitrary number of non-color channels. The current solution is generally to use separate grayscale images for each extra thing you want to store, which is inefficient since it loses the ability to compress the correlation between the separate channels. Another example usecase would be capturing images at 10 different wavelengths rather than the typical RGB.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: