Twitter | Search | |
Patrick Walton
Research engineer at Mozilla
9,209
Tweets
494
Following
9,811
Followers
Tweets
Patrick Walton 17h
Replying to @rikarends @rektide
A lot of C++ isn’t really applicable to a GPU context and being an extension to C++ means there are really weird things like “const” and “constant” meaning two very different things
Reply Retweet Like
Patrick Walton 18h
Replying to @rikarends @rektide
Vulkan gives you more flexibility than Metal does in various ways. Also I’m really not a fan of the way Metal Shading Language is based on C++. Better to just standardize an IR.
Reply Retweet Like
Patrick Walton 18h
Replying to @pcwalton
(2) There’s no high-profile language design decision you can point to and say “aha, that was a mistake!” No header files, for example. The slowness comes from a lot of smaller things that have real benefits, such as the borrow check.
Reply Retweet Like
Patrick Walton 18h
Rust compiler performance is hard to have meaningful discussions about because: (1) There’s no single part of the compiler which is slow. In fact the compiler is pretty well optimized.
Reply Retweet Like
Patrick Walton 18h
Replying to @rikarends
I’ve also heard that WSL has serious specification problems relative to SPIR-V, but don’t know the details.
Reply Retweet Like
Patrick Walton 18h
Replying to @rikarends
The opposite is more likely.
Reply Retweet Like
Patrick Walton Feb 1
Sorry, not interested in throwing away all our hard work on a parallel Rust implementation of restyling to a slower C++ implementation just because Google wrote the latter.
Reply Retweet Like
Patrick Walton Feb 1
Replying to @isiahmeadows1
That's nowhere near enough because of lack of uniform value representation
Reply Retweet Like
Patrick Walton Jan 31
Been pleasantly surprised at the amount of demand there is for fast vector graphics rendering in the browser. Time to get it done :)
Reply Retweet Like
Patrick Walton Jan 31
The vast majority of the time I don’t really care whether a symbol is public or private when I’m *using* it. Only at declaration does it really matter. And it is obviously a pain point for a lot of people.
Reply Retweet Like
Patrick Walton Jan 31
They did it anyway :)
Reply Retweet Like
Patrick Walton Jan 30
Replying to @NikolaiVazquez
Yes, see other replies
Reply Retweet Like
Patrick Walton Jan 30
Replying to @TimSweeneyEpic
Haskell has a uniform type representation. If you go down that road with a language like Rust you end up with Swift-like intensional type analysis, which gets hairy really fast.
Reply Retweet Like
Patrick Walton Jan 30
Seriously though, not having generics doesn’t make the problem go away—it just makes you choose between monomorphization or vtables manually as a programmer instead of having it be the compiler’s problem
Reply Retweet Like
Patrick Walton Jan 30
Replying to @WatsonLadd
Uniform value representation. Traditionally, all values in MLs are one hardware word. This simplifies things a lot.
Reply Retweet Like
Patrick Walton Jan 30
Replying to @TimSweeneyEpic
Note that Rust lets you change panic to abort for this reason, and the library ecosystem is designed such that libraries work without catchable panic enabled.
Reply Retweet Like
Patrick Walton Jan 30
For those asking for Swift witness tables/intensional type analysis: Rust used to have those, and generating all the virtual copy/get-align/etc functions for every type took like 30% of the compilation time as I recall. Monomorphization was a compilation time *win*.
Reply Retweet Like
Patrick Walton Jan 30
Replying to @trishume
We tried witness tables (intensional type analysis). It was a giant mess (I wrote a lot of that code). I suspect it wouldn’t be much faster at runtime than just having an interpreter, and an interpreter would be faster to compile.
Reply Retweet Like
Patrick Walton retweeted
Slava Pestov Jan 30
Replying to @jckarter @pcwalton
Maybe the real problem is that generics are actually bad
Reply Retweet Like
Patrick Walton Jan 30
Reply Retweet Like