|
|
Patrick Walton
@
pcwalton
San Francisco, CA
|
|
Research engineer at Mozilla
|
|
|
9,209
Tweets
|
494
Following
|
9,811
Followers
|
| Tweets |
|
|
Patrick Walton
@pcwalton
|
17h |
|
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
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
18h |
|
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.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
18h |
|
(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.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
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.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
18h |
|
I’ve also heard that WSL has serious specification problems relative to SPIR-V, but don’t know the details.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
18h |
|
The opposite is more likely.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
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.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Feb 1 |
|
That's nowhere near enough because of lack of uniform value representation
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
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 :)
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
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.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Jan 31 |
|
They did it anyway :)
gankra.github.io/blah/swift-abi/
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Jan 30 |
|
Yes, see other replies
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Jan 30 |
|
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.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
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
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Jan 30 |
|
Uniform value representation. Traditionally, all values in MLs are one hardware word. This simplifies things a lot.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Jan 30 |
|
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.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
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*.
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Jan 30 |
|
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.
|
||
|
|
||
| Patrick Walton retweeted | ||
|
Slava Pestov
@slava_pestov
|
Jan 30 |
|
Maybe the real problem is that generics are actually bad
|
||
|
|
||
|
|
Patrick Walton
@pcwalton
|
Jan 30 |
|
gankra.github.io/blah/swift-abi/ has some more info
|
||
|
|
||