Besides what is stated in the article, it is also important to have an inherently secure threat model. For example, full websites are inherently warm-blooded since you are constantly dealing with attackers, spam bots, etc. However, static pages like Tiddlywiki are a lot better since you can avoid putting it on the web at all and browsers are incredibly stable platforms.
I think it’s a completely valid point. Apple is still making (potentially a lot) of money off these old devices yet isn’t willing to fully support them. It seems very unethical.
I really wish JS had some sort of preemption for stuff like this. We have web workers now, but those work more like starting up another process since you can't pass functions to them.
You could add in continuation support as well as unbounded stack size to make it even more difficult to implement efficiently. There are tricks these days for implementing continuations somewhat efficiently (and by somewhat, I mean that they're only 3-5x slower than explicit continuation passing with lambdas), but these tricks largely don't work in WASM without doing something extreme like completely ignoring the WASM stack and storing return addresses/current continuation on the WASM heap.
Unbounded stack size is similarly difficult for WASM because like before, you have to be very careful about using the WASM stack.
Even with C++, you basically need to drop down to intrinsics or assembly to make full use of SIMD.
A photocopier is extremely different because the user is providing the copyrighted material. In the AI case, it is much more like writing a Google search for the copyrighted material. If I ask an artist to draw a cartoon of Mickey Mouse in violation of copyright, the artist is in violation of copyright if they produce said drawing and give it to me. Are we to give special rights to AI that human artists don't enjoy?
But is publishing a model which can generate images of Mickey a copyright violation? It's definitely a violation if the model is overfitted to the extent that you can, perhaps lossily, extract the original images.
Most people in the fanfiction community recognize that it's probably not strictly allowed under copyright. However, the community response has generally been to do it anyway and try to respect the wishes of the author. Hence why you won't find Interview with a Vampire fanfiction on the major sites.
If anything, I think that severely hinders the pro-AI argument if fanfiction made by human authors are also bound by copyright.
ETA: I just tested it out and you can totally create Interview with a Vampire fanfiction with Bing Compose. That presumably is subject to at least as strong copyright as human authors and is thus a copyright violation.
Apparently, even synthing doesn't think oblivious RAM (ORAM) is worth it. For those who haven't heard about it before, it's completely possible to abstract over a block storage device such that an attacker can't even determine things like which logical blocks are written to most frequently/correlations between writes on logical blocks.
Unfortunately, even though there are algorithms make each access only take log(n)^2, ORAM by definition makes caches on the server side not work at all. If the server can effectively service requests via cache, that means they can predict which memory cells are most likely to be used.
I think my preference is that it works instantly, but have some sort of indicator that it is syncing working. Users should be able to see when it is safe to assume state is consistent with what is on the server.
The reason why you don’t need some big, formal JSON schema (though they do exist) is because you can notate most of the constraints people care about in TypeScript. It’s just a bunch of structs, arrays, string enums, etc. XML doesn’t really have a nice mapping to type systems like that so it needs schemas.
My coup de grace against XML is that it is wholly unsuitable for serializing arbitrary strings in most programming languages. It’s defeated by quite simple strings like “hello\0world”. You can’t just escape the null using &#; because the standard, in its infinite wisdom, forbids it. Instead, you’re just expected to come up with some completely non-standard way like <null-char /> or just interpret “\0” specially in your application code. Meanwhile, JSON just lets you put pretty much whatever Unicode you want into a string with a standard way of escaping characters like the double quote.
I'd switch if they would support the File System Access API. It's a really convenient API and IMO as someone who has worked with it extensively, is very secure. It supposedly has privacy concerns, but I think it would primarily be used for FOSS and hobby projects since Bigco likes to store all the data on their servers anyways, that's a feature and not a bug for them. In fact, I think it would be a security/privacy improvement since it would encourage storing data locally (privacy) and is way more secure than asking users to install a native app (which has access to pretty much everything on the device and not just the directory/file a user gives it access to).
There are circumstances where it's a perfectly valid solution. For example, suppose you're trying to acquire the lock on something to destroy it. It can be the lesser of two evils just to leak that memory instead of just waiting forever/a very long time to acquire that lock. You just need to ensure that you aren't leaking memory too quickly for whatever your constraints are. For example, most programs wouldn't care about a 1kb/day leak of memory because that would take a very long time to actually become noticeable. Furthermore, there's pretty much always some degree of memory growth just due to heap fragmentation (at least if you're using a language like C which can't do memory compaction via GC).
I doubt it will reduce all that much. It’s still really convenient and it’s way more difficult to write and use a source generator than it is to just use reflection. Source generators will get used for stuff that really benefits from the extra safety and from the increased performance, but that still leaves many use cases for reflection.
It's sometimes useful for areas with a bit of hair, but not enough hair to protect the skin from the sun. However, if you do use spray sunscreen, also make sure to do it outside or other very well ventilated area.
The part that would be nice to bypass is TLB switching and cache invalidation. WASM doesn't need full page translation because it largely assumes the containing process already does that and because it doesn't support allocating non-contiguous memory without using multiple linear memories. Even with multiple linear memories, it still doesn't require (or event want) page translation because these memories each have their own address space.
The issue with if statements are that the stats/bits branch predictors use are a finite resource. You really need these checks to be inlined as well because otherwise you'll thrash the instruction cache. If it just had some special register with an interrupt, the CPU could just always assume the index is valid for the purposes of speculative execution and branch prediction.
This is extraordinarily difficult and sometimes impossible. Even first order logic is undecidable with regard to checking if a formula is decidable. That said, LEAN does leverage a SAT solver to try and do a bit of what you describe.
I wonder how much thermal throttling is going on with these benchmarks? 400W seems ridiculously difficult to cool. The 13900 was difficult if not impossible to cool for throughput without water cooling.
I think you could really speed up WASM a lot if CPUs supported the WASM sandbox better. For example, it would be nice to have modern segmented memory support where you could set an offset and max address such that all other pointer operations worked off that mini-TLB, generating an interrupt if the bounds are bypassed.
There's one huge problem WASM solves compared to other existing solutions: memory safety. Instead of running untrusted computational code in a separate process, you can run it all in a single process since WASM linear memory has bounds checking. It also combines this with extremely constrained API access giving you a way to sandbox code with almost native performance.
Besides memory checking, there are much fewer nasty things a process can do in terms of control flow since executable memory (procedures) do not exist in linear memory. It supports function pointers via a separate table system (kind of like having a separate address space for executable memory). All of this is in place so if a WASM module crashes, it doesn't take down whatever process it's running in.
I assume that serialization formats might reference this standard so that they don’t need to reinvent the wheel that is graph normalization.
> A canonicalization algorithm is necessary, but not necessarily sufficient, to handle many of these use cases.
It’s kind of like how there’s a standard for structured copy of JS objects that gets used for things like the web worker spec.
Signing something independent of serialization might be useful since then the exact serialization format can vary. For example, maybe the data is already serialized using SQLite. I’d prefer to avoid loading the data into memory and reserializing it just to check the signature. Instead, it’d be nice to just canonicalize it and then utilize the indexing capabilities of SQLite to minimize memory usage.
If you search for “isomorphism” in the doc, they state that most real world cases will have unique IDs for nodes and that make this efficient in practice and that implementations can detect if a case is difficult (likely aborting).
We're still missing a few things like continuations. However, full tail call support speeds that up a lot since then you don't need a trampoline function. I know there was a proposal for WASM continuations, but I think that got dropped due to complexity (I don't blame them, continuations are really tricky to optimize since they are such a powerful control flow tool).
I don't know, this time around there has been much more focus on security which was really what spelled doom for Flash/Java. That and it's actually included as part of web standards instead of being something that users have to download and update separately. I doubt that GC would have been added at all except that it's a requirement to speedup and simplify the boundary between the browser and WASM.
Given what I know about CUDA and assuming it's different from being able to call malloc within a kernel and paging memory between the CPU and GPU, I assume it's adding in some smartness for offloading stuff from the GPU when running multiple kernels. You want to keep stuff in GPU memory as much as possible since transfers can increase latency dramatically, but if you have multiple applications using the GPU then there might not be enough memory for all of them.
However, I'm always suspicious of how innovative patents actually are so it wouldn't surprise me to find out it's just barely different than what CUDA or unified memory on game consoles can do.
Old comment, but that's not quite right. The equivalent for implication is "assert(!someObj || someObj.data)" which is much more confusing to read. It's saying if someObj exists, then it should also have data. Upon reflection, I think a better example would be something like "assert(someObj.type == SomeObjType::Float => !isnan(someObj.data))". Without the new operator, it would be "assert(someObj.type != SomeObjType::Float || !isnan(someObj.data))" which doesn't make the intent clear.