wuffs
highway
Our great sponsors
wuffs | highway | |
---|---|---|
80 | 65 | |
3,695 | 3,559 | |
1.1% | 14.5% | |
9.4 | 9.8 | |
1 day ago | 7 days ago | |
C | C++ | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wuffs
-
Still no love for JPEG XL: Browser maker love-in snubs next-gen image format
Maybe this is what you are looking for:
https://github.com/google/wuffs
"Wuffs is a memory-safe programming language (and a standard library written in that language) for Wrangling Untrusted File Formats Safely."
-
Just about every Windows/Linux device vulnerable to new LogoFAIL firmware attack
This is one of the reasons I'm a big fan of wuffs[0] - it specifically targets dealing with formats like pictures, safely, and the result drops in to a C codebase to make the compat/migration story easy.
-
Google assigns a CVE for libwebp and gives it a 10.0 score
One example for a safer language developed at Google: https://github.com/google/wuffs
There are already huffman-decoding and some parts of webp algorithms in https://github.com/google/wuffs (language that finds missing bounds checks during compilations). In contrary, according to readme, this language allows to write more optimized code (compared to C). WEBP decoding is stated as a midterm target in the roadmap.
-
The WebP 0day
Specifically, since performance is crucial for this type of work, it should be written in WUFFS. WUFFS doesn't emit bounds checks (as Java does and as Rust would where it's unclear why something should be in bounds at runtime) it just rejects programs where it can't see why the indexes are in-bounds.
https://github.com/google/wuffs
You can explicitly write the same checks and meet this requirement, but chances are since you believe you're producing a high performance piece of software which doesn't need checks you'll instead be pulled up by the fact the WUFFS tooling won't accept your code and discover you got it wrong.
This is weaker than full blown formal verification, but not for the purpose we care about in program safety, thus a big improvement on humans writing LGTM.
-
What If OpenDocument Used SQLite?
> parsing encoded files tends to introduce vulnerabilities
If we are talking about binary formats, now there are systematic solutions like https://github.com/google/wuffs that protect against vulnerabilities. But SQLite is not just a format - it's an evolving ecosystem with constantly added features. And the most prominent issue was not even in core, it was in FTS3. What will SQLite add next? More json-related functions? Maybe BSON? It is useful, but does not help in this situation.
Regarding traces, there are many forensics tools and even books about forensic analysis of SQLite databases. In well-designed format such tools should not exist in the first place. This is hard requirement: if it requires rewriting the whole file - then so be it.
-
CVE-2023-4863: Heap buffer overflow in WebP (Chrome)
I agree that Wuffs [1] would have been a very good alternative! If it can be made more generally. AFAIK Wuffs is still very limited, in particular it never allows dynamic allocation. Many formats, including those supported by Wuffs the library, need dynamic allocation, so Wuffs code has to be glued with unverified non-Wuffs code [2]. This only works with simpler formats.
[1] https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang...
[2] https://github.com/google/wuffs/blob/main/doc/note/memory-sa...
-
NSO Group iPhone Zero-Click, Zero-Day Exploit Captured in the Wild
There are efforts to do that, notably https://github.com/google/wuffs
RLBox is another interesting option that lets you sandbox C/C++ code.
I think the main reason is that security is one of those things that people don't care about until it is too late to change. They get to the point of having a fast PDF library in C++ that has all the features. Then they realise that they should have written it in a safer language but by that point it means a complete rewrite.
The same reason not enough people use Bazel. By the time most people realise they need it, you've already implemented a huge build system using Make or whatever.
-
FaaS in Go with WASM, WASI and Rust
Here's an off-topic answer.
Depends on what you want your toy language to do and what sort of runtime support you'd like to lean on.
JVM is pretty good for a lot of script-y languages, does impose overhead of having a JVM around. Provides GC, Threads, Reflection, consistent semantics. Tons of tools, libraries, support.
WebAssembly is constrained (for running-in-a-browser safety reasons) but then you get to run your code in a browser, or as a service, etc, and Other People are working hard on the problem of getting your WA to go fast. That used to be a big reason for using JVM, but it turns out that Security Is Darn Hard.
I have used C in the (distant) past as an IL, and that works up to a point, implementing garbage collection can be a pain if that's a thing that you want. C compilers have had a lot of work on them over the years, and you also have access to some low-level stuff, so if you were E.G. trying to come up with a little language that had super-good performance, C might be a good choice. (See also, [Wuffs](https://github.com/google/wuffs), by Nigel Tao et al at Google).
A suggestion, if you do target C -- don't work too hard to find isomorphisms between C's data structures and YourToyLang's data structures. Back around 1990, I did my C-generating compiler for Modula-3, and a friend at Xerox PARC used C as a target for Cedar Mesa, and Hans used it in a lower-level way (so I was mapping between M-3 records and C structs, for example, Hans was not) and the lower-level way worked better -- i.e., I chose poorly. It worked, but lower-level worked better.
If you are targeting a higher-level language, Rust and Go both seem like interesting options to me. Both have the disadvantage that they are still changing slightly but you get interesting "services" from the underlying VM -- for Rust, the borrow checker, plus libraries, for Go, reflection, goroutines, and the GC, plus libraries.
Rust should get you slightly higher performance, but I'd worry that you couldn't hide the existence of the borrow checker from your toy language, especially if you wanted to interact with Rust libraries from YTL. If you wanted to learn something vaguely publishable/wider-interesting, that question right there ("can I compile a TL to Rust, touch the Rust libraries, and not expose the borrow checker? No+what-I-tried/Yes+this-worked") is not bad.
I have a minor conflict of interest suggesting Go; I work on Go, usually on the compiler, and machine-generated code makes great test data. But regarded as a VM, I am a little puzzled why it hasn't seen wider use, because the GC is great (for lower-allocation rates than Java however; JVM GC has higher throughout efficiency, but Go has tagless objects, interior pointer support, and tiny pause times. Go-the-language makes it pretty easy to allocate less.) Things Go-as-a-VM currently lacks:
- tail call elimination (JVM same)
-
Don't carelessly rely on fixed-size unsigned integers overflow
Because if you couldn't prevent creation of pointers from the thin air (e.g. by sending them to remove server and then pulling them from said server) then you can not prove anything of that sort and if you limit such operations then you are starting journey on the road to Rust or Wuffs!
highway
-
JPEG XL and the Pareto Front
[0] for those interested in Highway.
It's also mentioned in [1], which starts off
> Today we're sharing open source code that can sort arrays of numbers about ten times as fast as the C++ std::sort, and outperforms state of the art architecture-specific algorithms, while being portable across all modern CPU architectures. Below we discuss how we achieved this.
[0] https://github.com/google/highway
[1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., which has an associated paper at https://arxiv.org/pdf/2205.05982.pdf.
-
Gemma.cpp: lightweight, standalone C++ inference engine for Gemma models
Thanks so much!
Everyone working on this self-selected into contributing, so I think of it less as my team than ... a team?
Specifically want to call out: Jan Wassenberg (author of https://github.com/google/highway) and I started gemma.cpp as a small project just a few months ago + Phil Culliton, Dan Zheng, and Paul Chang + of course the GDM Gemma team.
-
From slow to SIMD: A Go optimization story
C++ users can enjoy Highway [1].
- GDlog: A GPU-Accelerated Deductive Engine
-
Designing a SIMD Algorithm from Scratch
At that point it is better to have some kind of DSL that should not be in the main language, because it would target a much lower level than a typical program. The best effort I've seen in this scene was Google's Highway [1] (not to be confused with HighwayHash) and I even once attempted to recreate it in Rust, but it is still distanced from my ideal.
-
SIMD Everywhere Optimization from ARM Neon to RISC-V Vector Extensions
Highway (https://github.com/google/highway), Google's SIMD library, lets you write length-agnostic SIMD code. It has excellent support for a wide range of targets, including both RISC-V and Arm vector extensions.
Interesting, thanks for sharing :)
At the time we open-sourced Highway, the standardization process had already started and there were some discussions.
I'm curious why stdlib is the only path you see to default? Compare the activity level of https://github.com/VcDevel/std-simd vs https://github.com/google/highway. As to open-source usage, after years of std::experimental, I see <200 search hits [1], vs >400 for Highway [2], even after excluding several library users.
But that aside, I'm not convinced standardization is the best path for a SIMD library. We and external users extend Highway on a weekly basis as new use cases arise. What if we deferred those changes to 3-monthly meetings, or had to wait for one meeting per WD, CD, (FCD), DIS, (FDIS) stage before it's standardized? Standardization seems more useful for rarely-changing things.
1: https://sourcegraph.com/search?q=context:global+std::experim...
2: https://sourcegraph.com/search?q=context:global+HWY_NAMESPAC...
-
Six times faster than C
You could study Google's Highway library [1].
-
10~17x faster than what? A performance analysis of Intel x86-SIMD-sort (AVX-512)
The vqsort README says it is a non-issue on that generation CPU based on their benchmarks: https://github.com/google/highway/tree/master/hwy/contrib/so...
What are some alternatives?
xsimd - C++ wrappers for SIMD intrinsics and parallelized, optimized mathematical functions (SSE, AVX, AVX512, NEON, SVE))
Vc - SIMD Vector Classes for C++
swup - Versatile and extensible page transition library for server-rendered websites 🎉
png-decoder - A pure-Rust, no_std compatible PNG decoder
DirectXMath - DirectXMath is an all inline SIMD C++ linear algebra library for use in games and graphics apps
riscv-v-spec - Working draft of the proposed RISC-V V vector extension
stb - stb single-file public domain libraries for C/C++
jpeg-xl
csharplang - The official repo for the design of the C# programming language
ispc - Intel® Implicit SPMD Program Compiler
nsimd - Agenium Scale vectorization library for CPUs and GPUs
image-png - PNG decoding and encoding library in pure Rust