nbpname

vor 6 Monatendiscuss

The value brought by NixOS is on line 6.

  --config ${config.sops.secrets."rclone.conf".path} \

NixOS let you build the abstraction you want, and mix them with abstractions provided by others, and this single line illustrates this point extremely well as `sops` is not yet part of NixOS.

Secret management would likely come in NixOS in the future, but in the mean time you can add either use https://github.com/Mic92/sops-nix or https://github.com/ryantm/agenix to make it possible to manage files which have content that should not be public.

Other package managers also provide some abstraction over the packages, and would likely see the same systemd configuration abstracted the same way in post-install scripts. Yet, the encrypted file for `rclone.conf` would come as a static path in `/etc`.

You could resume NixOS as having moved the post-install script logic before the installation, yet this tiny detail gives you additional abilities to mix the post-install scripts and assert consistency ahead of making changes to the system.

nbpname

vor 3 Jahrendiscuss

Grafting is indeed a good solution for fast security updates, except that the way this is implemented in Guix depends on the maintainer of each package. This is indeed better than Nix which relies on asking every user to replace the dependencies.

A few years ago, I made a proposal to have some automatic grafting mechanism: https://github.com/NixOS/nixpkgs/pull/10851

This would automagically work by simply maintaining 2 trees of Nixpkgs, one with the cherry-picked security updates, and one which matches the latest set of cached packages. This way one can fully benefit from the cached packages while having the ability to replaces with the latest security patches they want to import without building the world.

Unfortunately, rewritting Nixpkgs to fit the requirements needed to have the automagic mechanism is a huge project, especially given the activity of Nixpkgs. Maintaining a fork of Nixpkgs which stays up-to-date while changing its inner working cannot be held by a single person.

My hopes would be to push this to the Nixpkgs Architecture Team, while preventing them from doing mistakes by inserting extra complexity while making this work more challenging.

nbpname

vor 3 Jahrendiscuss

Interesting!

The current design seems to uses 3 transducers at 2.25 MHz with a static phase shifter added on top of the transducers. Then they capture floating / dropping particles which are moving past the design that they want to be printing.

I am currently working on building a similar mechanism as a pet project, inspired by the SonicSurface[1], with the goal of having a dynamic hologram while not requiring a huge computer hidden in the back.

[1] https://www.instructables.com/SonicSurface-Phased-array-for-...

nbpname

vor 6 Jahrendiscuss

I have similar results when running the code in the Firefox devtools console, however, running these benchmarks in a dedicated webpage does not show the results.

When using a dedicated web page, I see results which are in the same ranges as NodeJS and Chrome: (not comparable, as running on different hardware)

   Started data Local (original) foo.html:120:11
  Finished data locality test run in  8.6800 ± 1.3095  ms. foo.html:144:11
   Started data Non-local (original) foo.html:120:11
  Finished data locality test run in  38.9400 ± 1.6195  ms. foo.html:144:11
   Started data Local foo.html:120:11
  Finished data locality test run in  6.6600 ± 1.1390  ms. foo.html:144:11
   Started data Non-local foo.html:120:11
  Finished data locality test run in  38.6400 ± 1.5861  ms. foo.html:144:11
   Started data Non-local (sorted) foo.html:120:11
  Finished data locality test run in  12.1800 ± 1.8334  ms. foo.html:144:11
   Started data Local (object) foo.html:120:11
  Finished data locality test run in  14.4500 ± 1.1492  ms. foo.html:144:11
   Started data Non-local (object) foo.html:120:11
  Finished data locality test run in  49.0000 ± 1.6576  ms. foo.html:144:11
   Started data Non-local (sorted array of indices) foo.html:120:11
  Finished data locality test run in  53.8500 ± 2.9725  ms.

I opened a bug against the devtools console of Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1647276

nbpname

vor 7 Jahrendiscuss

I am no expert in the front-end of Firefox, but a search highlight files such as "tabbrowser.css" and "tabbrowser.js".

Have fun: https://searchfox.org/mozilla-central/search?q=&case=false&r...

nbpname

vor 8 Jahrendiscuss

This feature is really cool, however the ratio of parse-time and compile-time improvement is not always meaningful to end users. I would be curious to see the absolute & relative load-time gains.

When I was benchmarking Firefox on the same feature [1], back in November 2017, I noticed that reddit loads very little JavaScript that any improvement on it does not matter.

Also, I wish that the benchmark website domains were not truncated, such as "http://www.", and better distinguish websites such as "http://reddit." (for http://reddit.musicplayer.io) as opposed to "http://www.reddit." (for http://www.reddit.com).

[1] https://blog.mozilla.org/javascript/2017/12/12/javascript-st...

nbpname

vor 9 Jahrendiscuss

The goal is to optimize the code both at compile-time and at run-time. We need to optimize it at compile time to prevent slow start-up, and we need to optimize it at run-time to benefit from profile guided optimizations.

nbpname

vor 9 Jahrendiscuss

Both the reference to the GraalVM and a pun are intentional.

nbpname

vor 9 Jahrendiscuss

It sounds more than likely that HolyJit will use Cretonne as a backend.

For the moment it uses dynasm, just to get the prototype working, but I expect to change that in the upcoming months.

(I am the author of HolyJit)

nbpname

vor 9 Jahrendiscuss

For both SpiderMonkey and v8, this is counting the number of calls to the MacroAssembler. SpiderMonkey commonly use the prefix "masm", while v8 uses the macro "__ " to alias the MacroAssembler.

The MacroAssembler, is basically what is used to produce assembly code in both JavaScript engines.

nbpname

vor 9 Jahrendiscuss

Overlays is a way to extend Nixpkgs in a format which can easily be shared, imported and combined. An overlay can add or override packages, like any user could do before with packageOverrides.

An example of overlay is the rust overlay provided in the nixpkgs-mozilla[1] repository, which package all latest versions of the rust compiler[2].

[1] https://github.com/mozilla/nixpkgs-mozilla [2] https://github.com/mozilla/nixpkgs-mozilla/blob/master/rust-...

nbpname

vor 10 Jahrendiscuss

We have an addon called the "Jit Inspector" [1], which should report the Assembly produced by IonMonkey. Last time I tried it not all panels where functional because it was still making attempts at reporting data from JaegerMonkey, which got removed since.

The lastest solution I have seen so far is what we call the "Jit Coach" [2]. This is a devtools panel under the performance tab which reports if your function sticks in IonMonkey compiled code. Based on the MDN page this is behind a preference in "about:config".

When we compile, we record the hypothesis made by the compiler, and use these to annotate the deoptimization paths which are taken. Each time we jump back to Baseline the tool reports why we jump back to Baseline.

So far, only the front-end of IonMonkey and the deoptimization path are recorded. No other optimization phases are recorded at the moment. Sadly, it does not report the Assembly produced by IonMonkey.

[1] https://addons.mozilla.org/en-US/firefox/addon/jit-inspector...

[2] https://wiki.mozilla.org/DevTools/Performance/JIT

Submissions

Firefox 58 adds a JavaScript startup bytecode cache

IonMonkey now has Scalar Replacement and Branch Pruning optimizations

comments