Unless your memory allocator runs a form of garbage collection, which most of the advanced ones do! Worst memory performance issue I've ever seen was in a C++ program where the deallocation of a large object graph from one spot completely trashed the performance of the application across many threads...
HN user
bencyoung
Sounds like the Chronophage clock in Cambridge: https://en.wikipedia.org/wiki/Corpus_Clock. It it's purely mechanical but has odd pauses in the ticks etc
Sorry for the delay! It's fairly simple. 1. You have a column on your objects you want secured as an LTREE[] 2. You add a GIST index on that column
The values should be the different hierarchy paths to access the object starting with a "type" e.g departments.root.deptA
When you run a query, depending on how you want to access you use a <@ query. E.g. I'm a user with root access to all depts "col <@ 'departments.root'::ltree" or I'm a user in dept A "col <@ 'departments.root.deptA'::ltree" etc
Sorry for the delay! It's fairly simple.
1. You have a column on your objects you want secured as an LTREE[] 2. You add a GIST index on that column
The values should be the different hierarchy paths to access the object starting with a "type" e.g departments.root.deptA
When you run a query, depending on how you want to access you use a <@ query. E.g. I'm a user with root access to all depts "col <@ 'departments.root'::ltree" or I'm a user in dept A "col <@ 'departments.root.deptA'::ltree" etc
If you're using Postgres then using the ltree module is great for permission systems. Available in RDS too
Not majorly odd, just an area I thought Rust would be hot on when it comes to performance...
Having worked in HPC a fair bit I'm not a fan of autovectorization. I prefer the compiled code's performance to be "unsuprising" based on the source and to use vectors etc where I know it's needed. I think in general it's better to have linting that points out performance issues (e.g. lift this outside the loop) rather than have compilers do it automatically and make things less predictable
Odd that c# has a better stable SIMD story than Rust! It has both generic vector types across a range of sizes and a good set of intrinsics across most of the common instruction sets
Cheapest MSK cluster is $100 a month and can easily run a dev/uat cluster with thousands of messages a second. They go up from there but we've made a lot of use of these and they are pretty useful
Kafka is great tech, never sure why people have an issue with it. Would I use it all the time? No, but where it's useful, it's really useful, and opens up whole patterns that are hard to implement other ways
JIT compilation can be faster for compiled languages too, as it allows data driven inlining and devirtualization, as well as "effective constant" propogation and runtime architecture feature detection
I think this is exactly the same approach PyPy used 15 or so years ago! Partially evaluate the language runtime
I almost did a PhD with David but ended up working at Transversal instead, which was a company he co-founded to do some interesting work in the search engine space! It's what got me into software development as a career so I'm always grateful to him
The Fens in East Anglia in the UK has a lot of interesting pumping tech. The latest can do 100m3/s (https://www.edie.net/st-germans-pumping-station-keeps-fens-f...). If all the pumps failed there would be hundreds of km2 underwater within days or weeks
I think it's more that western cultural cliches become invisible to western audiences rather than moving on. E.g. the "superhero" is definitely a western cliche. "A lone operative defies the rules to do the right thing because might is right if you're right. Individual exceptionalism triumphing etc". Somewhat shallowly examined in some films but still turns up all over the place.
Dotnet is getting a fully interpreted mode in 10 or 11 so I wonder if they'll switch to that for things like this
We have https://www.myenergi.com/ for our car charger and it seems to be able to integrate batteries, charging and panels like you suggest, only you have to go all in. We have parts of it and are tempted to use more, but the lock-in angle is a bit off-putting
Ok I drilled down a bit and looks like you are right, although I'm still not sure I've built up a clear understanding! (https://physics.stackexchange.com/questions/187917/thought-e...). In fact that question (series of onions) is exactly how I visualised it...
I'm not quite sure from that discussion why an event horizon is equivalent to a body moving outwards at the speed of light but it does make some sense. GR is always fun!
I still don't have a good idea of the "slow moving crossing the event horizon" case" but I'll read around it some more
Maybe the difference is between "free fall through an event horizon" vs "hover" (as much as is possible) at an event horizon
Seems amazing similar to the changes a junior would make (jump to the solution that "fixes" it in the most shallow way) at the moment
Thanks! Hmm, I think we're talking about slightly different things but it's been too long since I studied it to put it in the right words :)
I completely agree that spacetime can be "flatish" for a large block hole, but the event horizon does still represent a boundary right?
Consider the edge case of crossing the event horizon itself at some speed <<c (because you've got magic thrusters fighting the pull). At some point your feet will be through the event horizon and your head won't be. Do you agree that at that point you won't be able to see your feet?
I agree that your head will pass through the future light cone of your feet, and so could do somethign to affect your head (by emitting something falling slower than your head), but I'm not sure any light rays could follow that path.
Some example PRs if people want to look:
https://github.com/dotnet/runtime/pull/115733 https://github.com/dotnet/runtime/pull/115732 https://github.com/dotnet/runtime/pull/115762
Apart from my MSci in Physics... Perhaps you could post some links to the spacetime diagrams you are talking about?
Well, I disagree. Light literally can't move in a direction that makes it further from the singularity once inside the event horizon. I don't see what space being flat or not locally has to do with that. Check https://en.wikipedia.org/wiki/Event_horizon#/media/File:BH-n... for an example.
If your head is further from the singularity than your feet then you can't see them.
Happy not to discuss further!
You can do plenty of experiments to see if you are falling, e.g. hitting the surface of a planet you are falling towards. The event horizon is a surface like any other with a location in space and you can definitely see when you hit it (it's the bit where no light is coming out). And once you've crossed it, literally no EM radiation can move further from the singularity
Consider that every "surface" inside the event horizon is like a stronger event horizon so passing through you'd certainly notice things like not being able to see your feet any more as the light wouldn't be able to travel out to your eyes! There would be a lot of other stuff happening too so you may not notice exactly, but the event horizon is definitely noticeable!
Looks very nice but the Absent functionality seems like a potential foot gun to me, easy to remove an entire WHERE clause and blow up a whole table! If I have a filter in sql query it's because I really want it to be used!
It's the usual rabbit hole if you search for it, but there are some useful comments here: https://astronomy.stackexchange.com/questions/58610/would-it...
The way I see it is every surface inside an event horizon is another slightly "stronger" event horizon
There are no stable orbits inside the event horizon, and my understanding is even things like atom vibration can't move further from the sigularity so I'm guessing timespans would be limited!
From what I remembe of Undergrad physics this isn't actually possible. According to GR, within an event horizon, space-like pths become "time-like" which effecitvely means the singularity is unavoidably "in the future". No matter how big a black hole is, you can't just drift around inside it as literally all paths lead downward (hence even light not escaping)
If you were inside a black hole you wouldn't be able to see light from "deeper" because it wouldn't be able to travel towards you.
This is not what we see within the universe, so I don't think we can be inside a black hole
Personally I think this is a really cool idea: https://experiments.withgoogle.com/paper-phone. Both mildly mocking and thought provoking at the same time!