Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wuffs’ PNG image decoder

nigeltao.github.io

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Wuffs’ PNG image decoder

#131

Post by pjmlp »

kbenson wrote: post #71
quotemstr wrote: post #38

Earlier quoted context omitted.

All of Windows (including the NT kernel) is written using the same basic proof model that Wuffs uses, except that the constraints are specified as annotations on top of C and C++ instead of as a new programming language. I prefer the annotation approach, TBH, but I'm glad to see people working on safety. Specifically, Wuffs (like Rust) has this problem where it tries to fill the same niche as C and C++ and improve on…

> I'm a big believer in technical continuity. IMHO, a lot of recent language developments should have instead been extensions of C, C++, Java, or Python. If that's what you really wanted, and if we always did that, then you would probably want extensions to Perl instead of Python, since it predated it slightly and was much more popular much earlier. Instead, I think what you're really asking for is language extension…

Not the OP, but I do share the sentiment of improving existing unsafe languages.

The C and C++ code in many relevant stacks is not going away, and many of us won't be ever be able to use D or Rust regardless of how much we like them.

UNIX clones, Windows, .NET and Java runtime implementation, WinUI/WinRT, Android (regardless of this week's annoucement)

So Microsoft Checked C, Microsoft SAL, Visual C++/clang/gcc lifetime analysers, Frama-C, hardware memory tagging, Pluton sandbox, CHERI,... are all welcomed improvements.

Re: Wuffs’ PNG image decoder

#132

Post by sam_goody »

Can someone please explain usage?

I assume this would not be useful on a web server, unless it could be used by Image-Magick or GD.

Is this targeting Software devs (like Chrome or Affinity Designer)? Is this meant to replace the default decoder somehow, for a user that wants to speed up his system? Is there some other use I am missing?

Re: Wuffs’ PNG image decoder

#133

Post by flohofwoe »

mleonhard wrote: post #61
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

IMHO if Rust had a "proper" way to transpile to C, then a "C-style subset" of Rust would be a perfect library-implementation language and something like Wuff wouldn't be needed.

Re: Wuffs’ PNG image decoder

#134

Post by adamrezich »

convery wrote: post #119
adamrezich wrote: post #62

Earlier quoted context omitted.

why? usually I only see this happen for misleading headlines and appending "(year)" to old articles that might be construed as recent. what's misleading about the actual article's headline? as far as I can tell it seems to be true.

The author of Mango posted a benchmark on Reddit: https://www.reddit.com/r/programming/comments/mld1ob/the_fas... load save ---------------------------------------------- // image: 1165 x 859 (1943 KB) 24bpp libpng: 19.2 ms 494.7 ms wuffs: 14.9 ms 0.0 ms mango: 10.0 ms 84.7 ms // image: 312 x 442 (43 KB) 32bpp libpng: 2.9 ms 18.3 ms wuffs: 0.4 ms 0.0 ms mango: 0.1 ms 7.3 ms // image: 160 x 120 (13 KB) 8bpp libpng: 0.…

Ah cool, it would be neat to see a response from OP about this!

Re: Wuffs’ PNG image decoder

#135

Post by kbenson »

pjmlp wrote: post #131
kbenson wrote: post #71

Earlier quoted context omitted.

> I'm a big believer in technical continuity. IMHO, a lot of recent language developments should have instead been extensions of C, C++, Java, or Python. If that's what you really wanted, and if we always did that, then you would probably want extensions to Perl instead of Python, since it predated it slightly and was much more popular much earlier. Instead, I think what you're really asking for is language extension…

Not the OP, but I do share the sentiment of improving existing unsafe languages. The C and C++ code in many relevant stacks is not going away, and many of us won't be ever be able to use D or Rust regardless of how much we like them. UNIX clones, Windows, .NET and Java runtime implementation, WinUI/WinRT, Android (regardless of this week's annoucement) So Microsoft Checked C, Microsoft SAL, Visual C++/clang/gcc lifet…

Yes, I'm not against improving existing languages. I just don't think it's always sufficient, so we shouldn't accept the false dichotomy of improving existing languages or creating and promoting the use of new ones to take advantage of new ideas and technologies to their fullest.

Even if Rust were to fully supplant C and C++ for at least systems programming[1], we should hope that within a few decades it's a risk of being supplanted by something else. To want otherwise is likely to inadvertently want stagnation and/or a language that while likely still improving, is having new technologies and concepts bolted on in increasingly convoluted manner, as they were not and could not have been considered when designing the language originally.

1: I think this is unlikely, if only because I don't see one language supplanting C, I see C's market cannibalized by a few different languages, with C always retaining some use.

Re: Wuffs’ PNG image decoder

#136

Post by pjmlp »

kbenson wrote: post #135
pjmlp wrote: post #131

Earlier quoted context omitted.

Not the OP, but I do share the sentiment of improving existing unsafe languages. The C and C++ code in many relevant stacks is not going away, and many of us won't be ever be able to use D or Rust regardless of how much we like them. UNIX clones, Windows, .NET and Java runtime implementation, WinUI/WinRT, Android (regardless of this week's annoucement) So Microsoft Checked C, Microsoft SAL, Visual C++/clang/gcc lifet…

Yes, I'm not against improving existing languages. I just don't think it's always sufficient, so we shouldn't accept the false dichotomy of improving existing languages or creating and promoting the use of new ones to take advantage of new ideas and technologies to their fullest. Even if Rust were to fully supplant C and C++ for at least systems programming[1], we should hope that within a few decades it's a risk of…

Yeah, that I can go along with.

Re: Wuffs’ PNG image decoder

#137

Post by nigeltao »

rurban wrote: post #60

Looks good, but has somewhat widely false claims: > SMHasher is a test and benchmark suite for a variety of hash function implementations. It can provide data for claims like “our new Foo hash function is faster than the widely used Bar, Baz and Qux hash functions”. However, when comparing Foo to CRC-32, be aware that a SIMD-accelerated CRC-32 implementation can be 47x faster than SMHasher’s simple CRC-32 implementat…

> smhasher implements both

Ah, I'm based on aappleby/smasher, which is what the original location (http://code.google.com/p/smhasher) redirects to. I didn't realize that you have a more active fork.

> not just 47x faster, but 5000x faster

It's 47x faster: https://github.com/rurban/smhasher/issues/189

Re: Wuffs’ PNG image decoder

#138

Post by nigeltao »

ashkankiani wrote: post #109

The author is now a new favorite person of mine. I've been working on my own language, and I have an incredible overlap with the features that Wuff has, specifically the coroutines, refinement types, the "facts" (which I had been inspired to implement from ATS with its proof threading), the io_buffer slice type, and the effects system. It's kind of shocking how much stuff there is on overlap, but it does give a good…

Thanks for the kind words!

Re: Wuffs’ PNG image decoder

#139

Post by nigeltao »

bschwindHN wrote: post #121

I recently wrote a Rust PNG decoder mostly for use in no_std contexts, and it was motivated out of wanting to decode emoji for a font rasterizer. I didn't really put any effort into optimizing it yet, though it does use miniz_oxide and it decompresses the entire image at once instead of per-scanline. I'm curious if it is at all competitive with the Wuffs decoder, I'm guessing probably not because I haven't put any ef…

> I'm curious if it is at all competitive with the Wuffs decoder

You could try adapting https://github.com/google/wuffs/tree/main/script/bench-rust-...

> https://github.com/bschwind/png-decoder

Note that statements like:

let bytes_per_scanline = ((header.width * header.bit_depth as u32 * header.color_type.sample_multiplier()) + 7) / 8;

can silently overflow a u32 if width is 0x800_0000, bit_depth is 8 and sample_multiplier is 4. Part of the point of Wuffs is to catch things like that (at compile time).

Re: Wuffs’ PNG image decoder

#140

Post by bschwindHN »

nigeltao wrote: post #139
bschwindHN wrote: post #121

I recently wrote a Rust PNG decoder mostly for use in no_std contexts, and it was motivated out of wanting to decode emoji for a font rasterizer. I didn't really put any effort into optimizing it yet, though it does use miniz_oxide and it decompresses the entire image at once instead of per-scanline. I'm curious if it is at all competitive with the Wuffs decoder, I'm guessing probably not because I haven't put any ef…

> I'm curious if it is at all competitive with the Wuffs decoder You could try adapting https://github.com/google/wuffs/tree/main/script/bench-rust-... > https://github.com/bschwind/png-decoder Note that statements like: let bytes_per_scanline = ((header.width * header.bit_depth as u32 * header.color_type.sample_multiplier()) + 7) / 8; can silently overflow a u32 if width is 0x800_0000, bit_depth is 8 and sample_mult…

> You could try adapting ...

Do you accept PRs for the Rust benchmarks? My code is nowhere near competitive to the Wuffs implementation, but it would be a fun goal to work towards.

> Note that statements like ... can silently overflow a u32

Thank you for catching that, I'll go through the entire codebase and try to fix those up.

That's a part of Rust that always makes me feel uneasy - the compiler will tell you if you're doing math with numbers of different bit widths, but it won't warn you in most cases about overflow. That would be a good addition to the Rust compiler, or at least a Clippy lint.

Post reply on HN