gparmer - Network

@krismicinski I guess I'm wrong with all of this as the MS transformation also serializes execution through rules, to ensure that the...

@krismicinski I guess I'm wrong with all of this as the MS transformation also serializes execution through rules, to ensure that the constants prune out unneeded execution. Inlining + constant prop wouldn't prune as they don't transform the execution order.

Sorry, guess I had to talk this all through on my own.

@krismicinski I guess that dead-code elim is also required to get rid of the rules that are no longer referenced by the queries...

@krismicinski I guess that dead-code elim is also required to get rid of the rules that are no longer referenced by the queries...

@krismicinski Sorry for @ing you on this, but you're the datalog authority to me ;-)

@krismicinski Sorry for @ing you on this, but you're the datalog authority to me ;-)

@krismicinski Is there a reason that we shouldn't just think of the magic sets transformation as applying inlining + constant...

@krismicinski

Is there a reason that we shouldn't just think of the magic sets transformation as applying inlining + constant propagation? Maybe adding the body terms is semantically different, but I can't grok how.

There's a lot of pomp and circumstance around magic sets, but I'm guessing it is mainly historical.

Am I missing anything?

Debugging macros that generate assembly has to be one of my least favorite debugging activities (even though it is at compile time).

Debugging macros that generate assembly has to be one of my least favorite debugging activities (even though it is at compile time).

This day is coming in hot. Half hour delayed pictures of the sunrise over Chesapeake Bay.

This day is coming in hot.

Half hour delayed pictures of the sunrise over Chesapeake Bay.

I would have never argued that inlined assembly was well-designed. However, the design of the x86_64 extensions to access higher registers...

I would have never argued that inlined assembly was well-designed. However, the design of the x86_64 extensions to access higher registers just baffles me.

It

1. hijacks an existing storage modifier (register) that everyone wanted to go away, to now have a completely different purpose,

2. moves register naming out of the inline block where it belongs, increasing ambiguity about the semantic of using those named variables, and

3. requires the use of out-parameters where clobber variables *should* be the answer.

Why was this the reality we ended up with?

Example: https://git.musl-libc.org/cgit/musl/tree/arch/x86_64/syscall_arch.h#n53

Regarding xsaveopt on x86 which is used by the OS to save vector registers:This instruction is supposed to only save registers if 1. those...

Regarding xsaveopt on x86 which is used by the OS to save vector registers:

This instruction is supposed to only save registers if 1. those registers aren't in an "initial state", and 2. if they've been updated since restored.

My question that someone might know: If `vzeroall` (zero all registers, assume no avx512) is called, does this result in more efficient saving of register state? E.g. does this put them into an "initial state"?

I ask because zeroing registers often doesn't modify their values. Instead, it just quickly updates register micro-architectural renaming meta-data. Given this, I wonder if an optimization enables data to not be saved in detail using `xsaveopt` as they are "noted" to be zero.

I'm not sure I can think of a good justification for the "initial state" optimization if this isn't the case.

I'd like to thank my neighbor for helping me have fine-grained commits.git -am "someone's burning trash, so I have to transfer...

I'd like to thank my neighbor for helping me have fine-grained commits.

git -am "someone's burning trash, so I have to transfer to my desktop"

Don't worry, this repo isn't code ;-)

On Intel's new APX extensions that increase the number of general purpose registers to 32....

On Intel's new APX extensions that increase the number of general purpose registers to 32. https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

I'd imagine that this increases the costs of system calls. An analysis.

Facts from the document and the OS recommendations:

- xsave/xrstor are extended to save/restore these registers. These instructions are typically used on context switch.
- The proposed system ABI requires the caller to save used new registers (caller-saved). This is similar to AVX.
- They add push2/pop2 instructions to push/pop two registers, and are maintaining a cache of these values.

I think that the following are true:

- On systems like Linux, these extensions might *speed up* system calls.
- On systems such as microkernels with fast IPC, they might *slow down* system calls.

Linux analysis:

As the registers are caller-saved, they should be saved at user-level by the compiler *before* the system call is made. Thus, the OS might not care to save them on system call (assuming they don't hold system call arguments). The normal (first 16) GP registers might be saved and restored *faster* given the new push2/pop2 instructions. However, when the system switches between threads, then the registers must be saved/restored. The new xsave/xrstor support will do so if they are used.

Thus, system calls might speed up on Linux by doubling the push/pop throughput.

Microkernel analysis:

Systems that might want to switch between threads *without using xsave/xrstor* might slow down. These systems might need to manually save/restore the registers. Since there are double the registers to save/restore, this can be a non-zero cost. At the very least, the additional 128 bytes of registers might cause an additional few cache lines of storage/overhead.

This all sounds pedantic, but optimized microkernels often have between 100-200 cycles of software overhead per-IPC system call.

I'm not at all saying that the APX extension is bad, or that its impact on system calls will be disastrous. But I am trying to understand its impact on microkernels.

Thoughts?

Some additional discussion here https://twitter.com/__gparmer/status/1683833929059520512

I'm cleaning up our x86_64 boot code, and made a dumb error when initializing page-tables. The fun part:I get a *KVM internal error*...

I'm cleaning up our x86_64 boot code, and made a dumb error when initializing page-tables. The fun part:

I get a *KVM internal error* when switching to the incorrect page-tables. Even well-used software will frequently fail for cases that are difficult to test.

Odd. I don't remember filming this.https://www.youtube.com/watch?v=urcL86UpqZc&list=TLPQMTAwNjIwMjPhRTkzZo06hw

Odd. I don't remember filming this.

https://www.youtube.com/watch?v=urcL86UpqZc&list=TLPQMTAwNjIwMjPhRTkzZo06hw

https://hackmd.io/p3VG_bK9TXOvtgh1oA2yZQ?viewI would never think that academia does anything bureaucratic well, but you better believe that...

https://hackmd.io/p3VG_bK9TXOvtgh1oA2yZQ?view

I would never think that academia does anything bureaucratic well, but you better believe that we'd have created a "conference planning subcommittee" long-ago to own decision making around stuff like this.

What happens in Rust: Having a committee of 17 people with most of them not engaged in a timely manner is a recipe for talking past each other, and for issues being raised after the "time" for decisions.

I think that one of the organizational "requirements" is to assign ownership and with it power and accountability.

Also, kinda strange to me that there is such a focus on "harm" as being the primary...

Also, kinda strange to me that there is such a focus on "harm" as being the primary issue.

https://hackmd.io/p3VG_bK9TXOvtgh1oA2yZQ?view

The primary issue is that the decision making procedures are broken, thus, people can manipulate (intentionally or not) the process to reverse decisions.

Thoughts on the followup to the Rust meltdown @ https://blog.rust-lang.org/2023/05/29/RustConf.html> "Still, we want to share some...

Thoughts on the followup to the Rust meltdown @ https://blog.rust-lang.org/2023/05/29/RustConf.html

> "Still, we want to share some steps we are taking to reduce the risk of something like this from happening again."

How about say "... steps to prevent this from ever happening again", so that if it does, it is understood that it is so far beyond what is allowable that people will suffer significant consequences.

Leadership doesn't leave things like this in a "grey area" of admitting allowable risk.

Also, allowing those who exercised poor judgement to voluntarily step down sends the wrong message. They should have been *removed* from their role.

The constant stream of bad decisions, and competent people quitting seems to implies exceedingly poor leadership in Rust governance.

Potential lifehack for those who benefit from background activity while working (cafe environment, music, etc...). I've recently added...

Potential lifehack for those who benefit from background activity while working (cafe environment, music, etc...).

I've recently added more songs from opposite ends of the "energy" spectrum to my "concentration playlist" (e.g. NIN's Wish, alongside Gotan Project's "Queremos Paz"). I was worried about the large variance pulling me out of the zone, but it has *significantly helped concentration*.

Give it a shot!

Thank you @marcbrooker for this post on open vs. closed loop workload generators. https://brooker.co.za/blog/2023/05/10/open-closed.htmlThe...

Thank you @marcbrooker for this post on open vs. closed loop workload generators.

https://brooker.co.za/blog/2023/05/10/open-closed.html

The number of times I've discussed the trade-offs in the past 4 years is tiring. Now I've just added this post to my group's required reading list! Thank you so much.

I've been wondering what everyone's been doing with their rotating disks. Now I...

I've been wondering what everyone's been doing with their rotating disks. Now I know.

https://www.youtube.com/watch?v=e-WakfBNHD0&list=TLPQMTcwNTIwMjNMlQuEZJM7Xg

Static assertions with integration into the lsp is an underrated superpower. Immediate feedback on program invariants is magical.

Static assertions with integration into the lsp is an underrated superpower. Immediate feedback on program invariants is magical.

Observation about live coding streams: I enjoy coding streams when they are using technologies I'm familiar with. It is useful to see...

Observation about live coding streams: I enjoy coding streams when they are using technologies I'm familiar with. It is useful to see how others approach the craft.

I find them intractable and almost useless if I'm trying to learn more than the surface-level of a technology.

I don't know what I expected going in, but this difference is pretty striking.

If I don't want to learn depth, and just get some exposure, the second class is useful, but I have to go in without any expectations beyond rote exposure.

Do others have different experiences?