HN user

mockery

383 karma
Posts0
Comments65
View on HN
No posts found.

Can someone shed light on these two steps in the approximation?

  *         since cos(x+y) ~ cos(x) - sin(x)*y
  *                        ~ cos(x) - x*y,
For the first, maybe it's an approximate identity I'd never heard of?

For the second, it seems like it relies on X being small, but in this code... Y might be small enough for sin==identity approximation, but X isn't, is it?

In addition to the sibling comments, one simple opportunity available to a JIT and not AOT is 100% confidence about the target hardware and its capabilities.

For example AOT compilation often has to account for the possibility that the target machine might not have certain instructions - like SSE/AVX vector ops, and emit both SSE and non-SSE versions of a codepath with, say, a branch to pick the appropriate one dynamically.

Whereas a JIT knows what hardware it's running on - it doesn't have to worry about any other CPUs.

Postgres WASM 4 years ago

Thanks, those are specific requirements I could definitely see WASM struggling to meet.

In my experience in a large+mature enough codebase (particularly one that is already multi-platform, like Postgres appears to be) many of those requirements are wrapped in an abstraction layer to allow targeting new platforms, but some requirements (like memory mapping) could definitely be dealbreakers if the target platform doesn't naturally support them.

This solution still seems awfully complex (and probably not very efficient) but I certainly see why it's probably the "easiest" option.

Postgres WASM 4 years ago

The first thing to point out is that our implementation isn't pure WASM. We attempted to compile Postgres for WASM directly from source, but it was more complicated that we anticipated.

Crunchy's HN post provided some hints about the approach they took, which was to virtualize a machine in the browser. We pursued this strategy too, settling on v86 which emulates an x86-compatible CPU and hardware in the browser.

I’m out-of-domain but very curious about this part - it seems like a pretty extreme solution with a lot of possible downsides. Does this mean the “just compile native code to WASM” goal is still far off?

The full game isn't playable on that page. I believe all three sets of assets (HLDM, Uplink, Hazard Course) are from demos or free products.

Making the full game playable would probably be less OK.

It's totally reasonable to lament duplicated effort, but it's worth pointing out that this particular attempt is from a company[0] whose business is Qt consulting - so it's easy to imagine that they might succeed (due to expertise, size, and motivation) where others have not.

The post also explains why they started from scratch vs. existing approaches - I'm not qualified to evaluate the claims, but I think they deserve some credit for explicitly talking through their reasons.

[0] https://www.kdab.com/

I think GP is reacting to the word "obligation" (I certainly did.)

I'd claim there are actions that may be "morally justifiable" yet not raise to a level that creates a "moral obligation." The word "obligation" implies (to me at least) some sort of guilt or culpability if you don't undertake the action.

In fact my instinct is that most morally justifiable actions aren't weighty enough to be obligations. Consider any "morally neutral" action (for example, eating an apple instead of an orange for a snack) - I would label such an action "morally justifiable" (since applying the rules of morality does not argue against it) but it's certainly not a "moral obligation" (even ignoring the fact that the alternative is also morally justifiable!)

You could perhaps argue there is no such thing as a "truly neutral" action to an omniscient observer, who can measure and predict the impact on total human happiness of any action with certainty. Such an individual would indeed have a much more restrictive set of "morally justifiable" actions available to them - fortunately we mortals aren't burdened with that level of insight or certainty!

Not GP, but the code in the article passes 'unsigned int mutex' by-value, and then operates on its address (which will potentially be at a different stack address on each invocation, and will certainly be different for different threads.) It won't serve its purpose at all.

To my eye, the code is fundamentally broken in a way that's surprising for an article trying to teach threading, and it's likely confuse someone unfamiliar with these concepts.

Perhaps confusingly, the term "immediate mode GUI" usually describes an API style. NOT an implementation detail.

It suggests a particular implementation, but in practice most nontrivial "immediate mode" GUI libraries (including egui [1] and the famous Dear-IMGUI [2] [3] ) retain some "shadow state" between frames. The existence or scope of that state is a (sometimes-leaky) implementation detail that shouldn't distract from the fact that the API presented is still "immediate mode."

[1] https://github.com/emilk/egui#ids

[2] https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-a...

[3] https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

It seems like the brownout should be publicized on the front page of github.com - or at least githubstatus.com ?

(Although I'm not an active git/github user, so maybe there's an even more more obvious place a naive user having issues would go to figure out what their problem is. Hopefully there's a helpful commandline error explaining the situation.)

Perhaps, but it's quite convenient for any software that wants to ingest PSD files without the (nigh-intractable) challenge of reimplementing the entirety of Photoshop's parser and rendering systems!

Most* PSD files contain a "preview" copy of the fully-flattened document (which is compressed.) Flat white image compresses far better, so that portion of the file doesn't take as much space.

Depending on what your layers look like (how many, how much they cover, etc.) it's not too surprising that the preview image could take a substantial fraction of the total file size (sounds like ~20% in this case!)

* I believe this behavior can be toggled off with an option.

Seems to me like you're tacitly agreeing with GP here - you're just making a claim about which currency system you trust more! (And attempting to convince others of the same position.)

Using GP's definition: "custom" engines -- i.e. engines that are not provided commercially by third parties it's pretty easy to argue Fortnite also uses a "custom" engine. (And that's not pedantry - they obviously have knowledge and access that no licensee could dream of.)

That said, tere are a decent set of AAA games that license Unreal (PUBG, State of Decay, Borderlands series, Arkham series, XCom series) but it's rare among the absolute biggest titles ("AAAA" if you will.)

Yes! The 010 Editor's templating language is a nearly unique (in my experience) hybrid between C-like declarations and imperative flow that's exactly what I want for parsing arbitrary binary files.

The template executes like a script (with conditionals and looping) and a line like "int32 myNum;" is actually just syntactic sugar for "read 4 bytes from the current file pointer and label it myNum." Their example probably does a better job explaining it than I can:

  struct FILE {
      struct HEADER {
   char    type[4];
          int     version;
          ushort  numRecords;
      } header <bgcolor=cLtGray>;
  
      struct RECORD {
          int     employeeId;
          char    name[40];
          float salary;
          if( file.header.version > 1 )
              int      numChildren;
          if( file.header.version > 2 )
              time_t   birthDate;
      } record[ file.header.numRecords ];
  
  } file;
( From: https://www.sweetscape.com/010editor/templates.html )

It's important to remember that "beyond a reasonable doubt" means exactly that: no "reasonable" person would doubt it. (The definition of reasonable is left to the jury.)

Some people seem to think "beyond a reasonable doubt" means the same as "beyond any shadow of a doubt" - but they are very different standards!

I didn't read the parent post as using it that way - I believe they're saying that any claim that "supply chain security" (of videos) will combat deep fakes* isn't necessarily a credible model of security considering that the "real" supply chain (of physical goods) isn't apparently particularly secure.

I don't think I actually agree, however. Things like hashing and cryptography make me inclined to believe a digital 'chain of custody' is easier to prove and validate than a physical one.

( *I'd never heard this before, but it's an interesting claim )

None of the audio samples play for me (In neither Chrome nor Edge... Other sites play just fine.)

Makes it very hard to evaluate claims of codec quality, which seems like the primary purpose of the blog post. :(

A mispredicted branch is incredibly likely to perform operations that would normally fault (consider misprediction of a null pointer check, for example...) I don't think it's feasible to have a (useful) version of speculative execution that can trigger a true fault, because the mispredicted branches are going to violate all sorts of software invariants.

"With the new AWS Secret Region, we are bringing the same tools and workflows that are already available for Top Secret workloads to customers with Secret datasets and workloads."

Does this mean they already had an AWS "Top Secret" Region?

By 'optical flow calculations' do you mean a linear extrapolation of the projected 'image-space' position of the ball?

If so, that seems like it would be insufficient since a thrown object doesn't move linearly, let alone its projection.

If not, then I'm curious what you're describing, and how it's much simpler than integrating an ODE?