HN user

nwlieb

54 karma
Posts0
Comments23
View on HN
No posts found.

One concern with PTWRITE is that it is somewhat "slow," at least according to this: https://community.intel.com/t5/Processors/Intel-Processor-Tr...

I wonder if this is a general issue relating to memory ordering or out-of-order execution, or whether this can be implemented more efficiently in a different extension.

Thank you for the linked article! Agreed on the huge potential for using these tools in production. The community could definitely benefit (even indirectly) by pushing for this kind of instruction set more widely.

Hi, love the article. You mention in the article that a hardware mechanism for tracing should exist -- have you investigated the intel_pt (processor trace) extension? I believe this uses hardware buffers and supports timestamping & cycle counters (at somewhat larger than instruction granularity sadly, although it might issue forced stamps at on branches, not sure).

You can also use the PTWRITE instruction to attach metadata to the stream which seems very powerful.

Hope we can see such an extension on AMD as well.

Say I wanted to rank my own personal collection of songs by retention/engagement— are there any open source libraries or crisp descriptions of algorithms/statistical models that one could use?

Is this a 1-1 comparison? If the ARM compile is compiling to ARM binaries then there might be less work/optimizations since it is a newer architecture. Seems like a test with two variables that changed. Would be interesting to see them both cross-compile to their respective opposite archs.

Related: is it possible to reliably maintain physical disk space quotas in Linux (similar to cgroups)?

Furthermore, is it possible to say how much "space" you would use if you were to create a file with a given size, accounting for block-size, fragmentation, and metadata? Matters such as block-size, inode usage, and metadata seem to make this very difficult even if you add special integration to the userspace application, for example by using stat or statfs. This could help prevent quota overruns for example.

These seem like hard problems unfortunately, and I suspect the best solution is to just create separate disk partitions for each quota group.

In my experience this is only true for C/C++ (with a decent amount of work to setup CROSSTOOL properly). As soon as you start to get into Python, and Python<->C++ interop, it becomes very leaky.

I heard that Google has some tools internally that build the Python interpreter with Bazel and use that in order to guarantee hermeticity, but that doesn't seem to be possible with public tooling (at least not without some major hacks, for example https://github.com/bazelbuild/bazel/issues/4286 )

It would be interesting to see how Google manages languages such as Python at scale (and other languages that have similarly leaky package management).

Why is the 16GB RAM + FHD screen (1080p) variant not available in the US and Canada? It seems like this has been a long-standing issue since at least the 9360.

This is very frustrating since I don't need the 4k panel (in fact I don't want it for resolution scaling reasons) however I absolutely do need the 16GB of RAM.

Mind boggling.

This is fantastic! The biggest standout feature in my opinion is workspaces. I've been using workspaces on a client project with many sub-projects and it has been a pleasure.

Shared modularized code without creating private npm packages or doing some "linking" magic has been wonderful for productivity. It's as simple as creating another local package and symatically everything else has remained the same as a regular npm package, plus the benefits of having immediately updating code. For anyone with a large modular codebase wanting to forray into a monorepo approach I highly recommend checking it out. They also released a blog post here detailing the feature: https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/