It's not about the bitset itself.
It's about how to organize and think about your flags.
The small visualization grid is fantastic for debugging, and the `word:bit` structure lends itself directly to organize your data in categories and display them as such.
It focuses on creating flamegraphs to view on e.g. https://www.speedscope.app/.
I wanted to use std::stacktrace, but they are very costly to evaluate, even just lazily at exit. Eventually, I just tracked thread and call layer manually.
If I understand correctly, you're tracking your call stack manually as well using some graph structure on linear ids? Mind elaborating a bit on its functionality and performance?
Also proper platform-independent function names were a pita. Any comments on how you addressed that?
Ive been thinking about using speed scope as a reference to make a native viewer like that.
Sampling profilers (like perf) are just so much easier to use than source markup ones. Just feel like the tooling around perf is bad and that speedscope is part of the solution.
About linear IDs: A call graph in general case is a tree of nodes, each node has a single parent and an arbitrary amount of children. Each node accumulates time spend in the "lower" branches. A neat property of the callgraph relative to a generic tree, is that every node can be associated with a callsite. For example, if a some function f() calls itself 3 recursively, there will be multiple nodes corresponding to it, but in terms of callsite there is still only one. So lets take some simple call graph as an example:
Let's say f() has callsite id '0', g() has callsite id '1', h() has callsite id '2'. The callgraph will then consist of N=5 nodes with M=3 different callsites:
Node id: { 0 1 2 3 4 }
Callsite id: { 0 0 0 1 2 }
We can then encode all "prev."" nodes as a single N vector, and all "next" nodes as a MxN matrix, which has some kind of sentinel value (like -1) in places with no connection. For this example this will result in following:
Node id: { 0 1 2 3 4 }
Prev. id: { x 0 1 2 2 }
Next id matrix: [ 1 2 3 x x ]
[ x x 4 x x ]
Every thread has a thread-local callgraph object that keeps track of all this graph traversal, it holds 'current_node_id'. Traversing backwards on the graph is a single array lookup:
current_node_id = prev_node_ids[current_node_id];
Traversing forwards to an existing callgraph node is a lookup & branch:
next_node_id = next_node_ids[callsite_id, current_node_id]
if (next_node_id = x) create_node(next_node_id); // will be usually predicted
else current_node_id = next_node_id;
New nodes can be created pretty cheaply too, but too verbose for a comment. The key to tracking the callsites and assigning them IDs is thread_local local variables generated by the macro:
When callsite marker initializes (which only happens once), it gets a new ID. Timer then gets this 'callsite_id' an passes it to the forwards-traversal. The way we get function names is by simply remembering __FILE__, __func__, __LINE__ pointers in another array of the call graph, they get saved during the callsite marker initialization too. As far as performance goes everything we do is cheap & simple operations, at this point the main overhead is just from taking the timestamps.
Very exciting. CLIP and latent space embeddings in general are such an intuitive to use and powerful tool.
I'm using it in some hobby projects, from semantic image search in private collections, to trading card recognition among tenthousands of cards.
Love to see more open source work from big players on this.
Well, actually does in a lot of cases. For example line intersections are completely branchless in PGA. Parallel lines simply give you the according point at infinity. Pretty kool!
It's not a question of division by zero type of things. It's more about rounding errors, classifications, and topology. Does a point lie on one side of a plane or the other? Are two points actually the same? Are surfaces coincident? These are all questions with discrete answers and dealing with them is far harder than picking a more abstract representation of a few primitives and operators.
Example: Two boxes are in contact face to face. Think two 2x4s laying one on top of the other to form a cross. If I want to create a union of these objects, the surfaces that are in contact need to be cut into 3 areas each - one on each side of the other box, and a middle (contact) area that will be discarded. Where do I split the edges? Obviously where they intersect the plane of the other object. But the plane we need to intersect is the one parallel to the edge. We can often get away with splitting against the orthogonal plane, but only if it's a sharp edge. If it's rounded we end up with 3 surfaces all tangent at the intersection. So maybe I should look for edge-edge intersections. Right. But what if some code splits a line against a line, but another line is split against a plane? numerically these may be different results, but I know they should be the same point. I'm rambling because this is exactly a problem I was working on last night (aiming to fix a bug in Solvespace) and the solution has absolutely nothing to do with details like what abstraction is used to represent the geometric primitives, and everything to do with numerical precision and topological representations. These are the hard problems GA does not address.
Nova Sky Stories | C++/Qt Developer & WebDev | Munich, DE | Onsite, Hybrid | Full-Time
Nova Sky Stories empowers producers and artists to bring art to the skies of every city and town in the world with the most advanced light drone technology.
We are looking for a Software Engineer (C++/Qt) and Web Developer (Full Stack) to support our Munich-based engineering team.
Our new office in Gilching has plenty of space, a roof terrace, darts, cantina and cosy work places waiting.
You'll help us expand various aspects of our ecosystem, from show planning, animation design, to swarm control, data analysis and our art library.
Send us a note at stars@novaskystories.com with your motivation and CV.
We're looking forward to hearing from you.
A real-time LaTeX typesetter that outputs downloadable pixel art! The custom MINIGENT font consists of an extensive set of letters and symbols, including the whole greek alphabet, most used math and logic symbols, and even emojis!
I wrote a program to let a ball roll down the brachistochrone and compare it to other curves as my final school project some years ago. Might help some to get a better idea of it.
I like that you also have the ball sliding when the initial part of the track is near vertical. My German isn't good enough to read easily - is there a way of varying the coefficient of friction? Setting that 0 simulates the traditional problem where the falling object slides, and setting it to a very high value gets closer to the situation where some of the energy is taken into the rolling, and not into the speed of the ball.
The company that made the video and builds those drones, Ascending Technologies GmbH, is developing high-end systems targeted towards industry and universities. As far as I know, they have the only triple redundant flight controler and their own gps, which in combination is one of the most precise solutions their is [1]. It compensates winds of up to 15 m/s on its own. Their technology also powers the upcoming Volocopter [2].
So as surely the consumer drones get better and better each year, their is something to be have for a bit more money, right? ;)
Adressing object avoidance.
Intel and AscTec are ahead in the game ;) [1]. But I agree that this indeed will become more and more prominent and really interesting in the coming years!
"[...] Someday obstacle avoidance technology in UAVs will be like seatbelts in cars: You simply don’t start going without it!” [2]
Around 2002 two german guys set the path for today's quadcopters. They built the X-UFO and developed the X-3D and X-3D-BL sensors [1], which for the first time enabled amazing control capabilities for the still rather unknown quadcopters [2]. This led to the first success stories and the market kind of jumped on the train. Media did it's job and here we are. Technology has advanced a lot since then [3, 4]. Better and smaller sensors and microprocessors. More sophisticated materials and design, production and marketing processes. This surely played a big role as well, now that consumer market UAVs and flying toys can be produced quite cheaply. Also various open source projects popped up and nowadays even beginners can build and program their own quadcopter and PID controller.
As for helicopter vs. quadcopter - The latter is much simpler to fly, especially with autopilots and control units such as the X-3D or today's AscTec Trinity. Also safety for consumer products is an issue, where quadcopters with their embedded propellers have the bonus. And its omni-directional nature of movement yields more freedom and fun, especially as a toy.
It's not about the bitset itself. It's about how to organize and think about your flags.
The small visualization grid is fantastic for debugging, and the `word:bit` structure lends itself directly to organize your data in categories and display them as such.