praeclarum

6 ms·

1.
by praeclarum 3y ago
Yes that syntax works right now.
2.
by praeclarum 3y ago
Yeah I think I’ll reduce the accuracy requirement for some transcendental functions since GPUs seem all over the place.
3.
by praeclarum 3y ago
Please do. I have a few test machines but cannot match the variety of hardware out there.
4.
by praeclarum 3y ago
Sorry Safari does not support WebGPU yet. Please join me in writing to Apple and requesting it.
5.
by praeclarum 3y ago
Yeah this is the trick. You need to maximize the use of workgroup parallelism and also lay things out in memory for those kernels to access efficiently. It’s a bit of a balancing act and I’ll be working on benchmarks to test out different
6.
by praeclarum 3y ago
Yeah so the thing is WebGPU doesn’t correctly support IEEE floating point. Particularly, 0 is often substituted for +-Inf and NaN. See section 14.6 of the spec. https://www.w3.org/TR/WGSL/#floating-point-evaluation
7.
by praeclarum 3y ago
Those are niceties and can be implemented with some small hacks. Most big nets do very little slicing. Lots of dimension permutations (transpose, reshape, and friends) but less slicing. I personally use a lot of slicing so will do my best t
8.
by praeclarum 3y ago
I’m of the same opinion. While I think I will keep the standard parameter order from torch, I will include the options overload to give all the benefits you describe.
9.
PyTorch ported to TypeScript using WebGPU(github.com)
6 points by praeclarum 3y ago|1 comments
10.
by praeclarum 3y ago
I've been working on a WebGPU optimized inference and autograd library with an API that matches PyTorch. The goal is to reach CUDA speeds in the browser. Many kernels have been implemented and it's been designed to be easily exten
11.
Show HN: Neural Network Translation Running in the Browser with Transformers-JS(transformers-js.praeclarum.org)
1 points by praeclarum 4y ago|0 comments
12.
by praeclarum 6y ago
It’s open source and I have successfully compiled and ran it on my own machine. So I do not fear it going away. The biggest risk is it could not be updated at some point. But, again, OSS. The community could continue the work.
13.
by praeclarum 6y ago
I owe the iCircuit community vacuum tubes. I've been promising them for some 10 years now. My hesitance has mostly been my inability to verify the simulations. I prefer to have physical elements available so I can double-check the ap
14.
by praeclarum 6y ago
Nailed it. I started iOS development using Obj-C++ but switched to C# after a couple years because of my familiarity and comfort in that ecosystem. At this point I've used it for 10 years on several iOS and Mac apps and know its ins an
15.
by praeclarum 6y ago
There is tons of TPL (Task Parallel Library, async and await), I was just trying to keep the blog simple. Once you have thread-safe primitives, you can build higher level abstractions on top of those. In fact I worked a bit on the TPL when
16.
by praeclarum 6y ago
What you call gaming, I call working around the government’s idiotic visa requirements.
17.
by praeclarum 10y ago
This is a priority for the next update - git just ended up being a lot of work and got cut for the initial release.
18.
by praeclarum 10y ago
Yes three is absolutely a toggle switch. C# and F# are mostly tolerant of this style of programming. But if you like writing "while" and "for" loops then the eager execution can really hurt. Also, if you do a lot of CPU
19.
by praeclarum 10y ago
At least on an iPad Pro, I have found the split view with Safari docked to the right to be very adequate (actually, good) as the app contains lots of links to online docs.
20.
by praeclarum 10y ago
I worked hard to make sure F# got equal support to C# - semantic highlighting, code completion, all that. The only real difference is the F# builds are a bit slower than C#.
21.
by praeclarum 10y ago
If you develop a cool app and want to distribute it on the App Store, then you will indeed have to transfer it to a Mac and recompile it there using Xamarin's free product. This is a mix of limitations of Continuous (doesn't have
22.
Combining React and F# to Make a Drone Design Site(praeclarum.org)
1 points by praeclarum 11y ago|0 comments
23.
by praeclarum 12y ago
The truth is they are essentially the same. I just draw the distinction because porting apps between them isn't always automatic.
24.
by praeclarum 12y ago
Windows RT (aka Metro, aka Store Apps). It's a model based on WPF but not fully compliant - it took in lessons learned form Silverlight. Call it WPFlight.
25.
by praeclarum 12y ago
Sorry - I have a very client-side/consumer facing attitude and these low level debuggers just don't matter. But I acknowledge that it's certainly useful in the scenario you outlined. Thank you for the clarification!
26.
by praeclarum 12y ago
What got me interested in the CLR in the first place was how easy it is to write a compiler for it. When insomnia hits, I'll still load F# and write a little parser and code emitter for some silly language I have been thinking of. It&#
27.
by praeclarum 12y ago
In fact it runs quite well on .NET. My favorite demo is seeing how much faster Eclipse loads on the .NET runtime than the Java.
28.
by praeclarum 12y ago
Mono has a lot of GPL code. Xamarin has a license to impart commercial licenses to their customers. So Xamarin customers are fine. Mono users will have to abide by the GPL'd bits. Microsoft's CoreCLR is MIT licensed. Nice. :-)
29.
by praeclarum 12y ago
In terms of maturity and feature-completeness, GTK# is the answer. Unfortunately, it's no beauty either. Especially on Mac it does its own control rendering and, while it tries to match the OS, has problems. XWT was meant to replace GT
30.
by praeclarum 12y ago
AFAIK WPF is managed by the Windows team. All this open sourcing has been happening form the Azure and developer teams. Chances of Windows open sourcing some of their code? Less likely. As someone who worked on WPF though, I will comment th

More ›