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

91–100 of 144 posts

Re: Wuffs’ PNG image decoder

#91

Post by saagarjha »

andrewla wrote: post #33
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…

The language itself is a little unreadable at first glance, but the idea of it is a very good one. sbt [1] is an amazing project for small embeddable toy programs, but using fuzzers rapidly shows how unsafe the code is, and the benchmarks in the original article show the extent of performance compromises made to make it work. It seems like this would be an interesting approach to a lot of security programming where i…

*stb; sbt is something entirely different :)

Re: Wuffs’ PNG image decoder

#92

Post by saagarjha »

miohtama wrote: post #59

First time hearing about Wuffs. It says Wuffs compiles to C. In this case, will the choice of C compiler affect the performance?

Yes:

> Note that gcc10 performs slightly faster than clang9 in Wuffs’ benchmark numbers at the top of this post (as well as in an earlier non-SIMD Adler-32 implementation), although clang9 sometimes performs better for the other C mimic libraries.

Re: Wuffs’ PNG image decoder

#93

Post by saagarjha »

CyberRabbi wrote: post #84

> Wuffs is not a general purpose programming language. It is for writing libraries, not programs. The idea isn't to write your whole program in Wuffs, only the parts that are both performance-conscious and security-conscious. Aren’t all apps (anything not one-off scripts) performance and security conscious? Being performance and security conscious seems like the rule, not the exception.

Generally code that deals with untrusted input often needs to balance the scale more towards security than other parts of the program might.

Re: Wuffs’ PNG image decoder

#94

Post by NickPollard »

nyanpasu64 wrote: post #65
NickPollard wrote: post #63

Earlier quoted context omitted.

I've not been following recent Rust development as closely, can you elaborate on what limited form of dependent types Rust is adding?

Functions and types can take integers as monomorphization-time template parameters (const generics). It would be nice if you could pass (n, t) where n is supplied at runtime, the type of t depends on the value of n, and the compiler only lets you use t if your code is valid for all reachable values of n. eg. fn(n: usize, arr1: &[i32; n], arr2: &[i32, n]) allowed the function body to assume the two slices can be zippe…

> Functions and types can take integers as monomorphization-time template parameters (const generics).

Const generics aren't dependent types though; you're still dealing with known constants at compile time. For it to be dependent types, you need something like in your latter example, where a type is dependent on an actual _value_ passed to a function at runtime.

Re: Wuffs’ PNG image decoder

#95

Post by nigeltao »

matu3ba wrote: post #31

Are there any compiletime benchmarks? I would be interested how much their approach scales in terms of code size, since they use likely SMT solvers to guarantee having no arithmetic overflows (which is more than Rust guarantees). Ideally as comparison with compile times of Rust programs.

> Are there any compiletime benchmarks?

It used to take a couple of seconds to compile Wuffs' standard library. It's back down to a few hundred milliseconds.

https://nigeltao.github.io/blog/2020/dumbindent.html#compila...

Re: Wuffs’ PNG image decoder

#96

Post by nigeltao »

matu3ba wrote: post #40
aw1621107 wrote: post #35

Earlier quoted context omitted.

> since they use likely SMT solvers to guarantee having no arithmetic overflows At least based on a quick skim of the docs, they use a combination of programmer assertions, interval arithmetic, and their type system for bounds checking and ensuring no arithmetic overflows.

Checked as well. They can only do this, because they require that heap memory owned by pointers does not get fragmented. So programmers must manage pointer offsets to each heap structure themself. Hence you never get potential pointer soup (pointers pointing to subparts and pointing to other things), which Rust resolves with pointer lifetime checking. Also loop invariants etc must all be annotated. I would be more in…

> programmers must manage pointer offsets to each heap structure

I'm sorry but I don't understand this statement. Can you re-phrase it?

> I would be more interested how they plan to handle IO effects or if they want to omit that.

I'm not sure exactly what you're asking for, but see the Coroutines, Effects and I/O pages in https://github.com/google/wuffs/tree/main/doc/note

Re: Wuffs’ PNG image decoder

#97

Post by Stanzilla »

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…

I don't understand why he just doesn't use Rust instead. The speed difference can't be that big.

Re: Wuffs’ PNG image decoder

#99

Post by nigeltao »

dividuum wrote: post #4
1-6 wrote: post #3

I wonder if the same performance benefits apply to Encoding PNGs.

Looks like there isn't an encoder for PNG: https://github.com/google/wuffs/tree/main/std/png Given the project goals, I guess most encoders don't make a lot of sense: For image encoding you basically provide an "x * y * bytes_per_pixel" memory area and an encoder does its magic on that. There isn't really any complicated untrusted input in that case.

> Looks like there isn't an encoder for PNG

There isn't one yet, but I'd like to have one at some point.

https://github.com/google/wuffs/blob/main/doc/roadmap.md

Re: Wuffs’ PNG image decoder

#100

Post by nigeltao »

FounderBurr wrote: post #89

Despite the intent to push “wuffs a 21st century programming language”, nothing here is presented that couldn’t be achieved by just applying the same limitations/optimizations to the current libpng code.

That could get to parity with "Fastest", but it wouldn't match it with "Safest".
Post reply on HN