To make sure that resources are compliant I would suggest using AWS Config Rules as they allow to specify for example that tags need to be applied. Validation of resources is done in a lambda function which should in theory allow to terminate the resources if they are not compliant.
Containers are just namespaces, mount, user, pin, and network namespaces.
The reason why chroot is not enough is that you want to allow a different pace of using certain dependencies is different applications. In a way its similar to how Mac OS packages applications as they all ship their own prefix root so to say.
Luckily, Trump is going to make America great again and will keep all those manufacturing jobs where owners don't like to pay minimum wage because they can't afford to pass on the raise because nobody wants to buy cheap apparel at this price point.
While I understand why the author is complaining, he should much rather complain to all his potential customers that make a purchase decision based on price instead of ethically supporting american workers.
I'm really waiting to see all those voters spend significantly more on "Made in Great America" apparel to make sure to keep all those jobs...
I love D language, and all what it needs is a high profile production project that uses D. and then more people will look into considering using D in their production environment.
Totally agree, in the paper they only look at competitive programming contests. Ideally, it would be interesting if the same could be applied to a larger code base with more authors and if it's possible to find a particular author in such a code base.
Something that is (typically) left out in these articles about how expensive rent in SF is, is that even for tech folks with rather high income the city becomes too expensive as soon as you have family. It might be ok to pay 2.5k per bedroom when you're single, but when you pay an additional 1.5k per child in daycare perspective changes.
In my opinion, if the trans-bay (e.g. Oakland to San Mateo) and around-the-bay (Berkeley - SJ) public transport would be reasonable in terms of time, things could normalize easier. It could take some pressure of the rent market as more opportunities could be found in other places.
Childcare expenses and lack of affordable housing options for a family of four are two of the primary reasons my wife and I moved away.
I really didn't feel like being on the hook for a $6,000/mo mortgage for the next 30 years. It'd still be a mediocre home at best and I'd never see my kids because I'd be out hustling trying to pay for it.
There's actually a huge difference: if you use __builtin_expect the slow path is still part of the function.
If the fast path is small enough, you probably want to inline the function, but the slow path makes it large enough that the compiler doesn't inline it (for good reasons).
If you force the slow path into a separate function, then your function becomes fast path + a call instruction, and it can be inlined.
I've often done this manually, and this is a very cool trick that I'm going to adopt immediately.
EDIT: plus, it's also beneficial for instruction cache/iTLB, as cornstalks pointed out.
This is so strange! If something is unlikely to execute, it is unlikely to execute due to a condition, which you clue the branch predictor as unlikely and the layout thingy as out of line. Why would something be unconditionally unlikely to execute?! I don't understand what a lambda buys you here.
In theory, the lambda combined with the noinline attribute forces the compiler to use a call/ret to a function rather than making a local jump. Since the function usually will have alignment requirements, this often will mean the error handling is in a different 64-byte cache line. If this error never occurs, this cache line will never occupy space in the instruction cache (i-cache), and useful instructions can be held there instead.
In practice, I'd be surprised if you can come up with a case where this makes a significant difference. If you are on a hot enough path for this to matter, on a modern processor you probably are running out of the even lower level decoded µop cache, which doesn't cache µops for branches that are not taken. If you aren't in this cache, your efforts are probably better spent making this happen.
Edit: ot's comment about how this affects the size of the parent function and whether it will be inlined is a good point, and might well make a measurable difference in the cases where it is true.
Author here. I use this trick for a general 'bail out with error code' throw macro. By definition it's the exceptional case and so I'm happy to take the hit of going out of line. It's a macro used all over a very large codebase and so it made sense to do this. And yes, in some cases it helps the compiler inline more aggressively where it does matter.
It's similar, but the whole point of the trick here is to move the generated code so it doesn't "pollute" the instruction cache in the CPU. __builtin_expect still puts the error-handling instructions right next to the rest of the code. The lambda puts the error-handling instructions elsewhere.
Whether or not this will impact performance depends, and will need some careful profiling. But I can imagine some situations where keeping the "hot" instructions in the cache and the "cold" (error-handling) instructions out of the cache could be beneficial.
> __builtin_expect still puts the error-handling instructions right next to the rest of the code. The lambda puts the error-handling instructions elsewhere.
Surely that's a decision for the optimizer to make, in the case of __builtin_expect?
