The knapsack problem gets much harder as you increase the dimensions.
Placing parts on a PCB is harder if you have to care about where the components go relative to each other (e.g. because they have to be electrically connected, a certain distance from ink marking or drill holes, due to thermal or interference issues etc) rather than just optimizing space used.
I had this guy as a prof. https://en.wikipedia.org/wiki/David_A._Klarner I have never encountered someone so excited about dividing up rectangles, as it is related to combinatorics. Also with such a seething hatred for floating point numbers.
I guess it's not really that necessary now that most sites load 25MB of JavaScript and a 250MB video that plays onload.
https://mozillagfx.wordpress.com/2021/02/04/improving-textur...
Plus there are a fair few programs that render text by rendering the font into a texture atlas once and then using the GPU to copy from the atlas. Your terminal emulator may be doing this, for example.
AKA "static memory allocation", since the heights of the rectangles can be interpreted as buffer sizes, and their widths as lifetimes.
Most of my PhD's effort has been devoted to beating the SOTA in this. Problem's importance nowadays is owed to deep learning's memory wall.
http://adambuchsbaum.com/papers/dsa-stoc03.pdf
https://link.springer.com/chapter/10.1007/978-3-540-27798-9_...
https://users.cs.northwestern.edu/~pdinda/ics-s05/doc/dsa.pd...
there are also some from ML people trying to allocate memory optimally for DNNs:
https://arxiv.org/abs/1907.01989
https://arxiv.org/abs/1804.10001
https://arxiv.org/abs/2001.03288
they all boil down to a couple of greedy heuristics. the most recent "cool" paper was from a group at google
https://dl.acm.org/doi/10.1145/3567955.3567961
basic idea is to use both ILP and heurstics. i asked them to open source but no dice :(
Papers-and-code-wise, I haven't published the "final" thing yet. Right now I'm looking into integrating it with IREE, to get some end-to-end figures.
clever guy. IREE is just about the only serious/available runtime where you can do this because IREE codegens the runtime calls as well as the kernel code. But you're gonna have to either patch an existing HAL or write a new one to accomplish what you want to accomplish. If you want I can help you - if you go to the discord (https://discord.gg/J68usspH) and ask about this in #offtopic I'll DM you and can point you to the right places.
lol i similarly spent 1 year of my phd trying to finagle this same thing for the same exact reason. got as far as proving that when it's parameterized (like in the case of DNNs with algebraically coupled layers) it's FPT (finite parameter tractable) which is like duh but also as soon as i found that i gave up (not much more to be done <shrug>).
I know that DSA is NP-complete, and none of the existing deep learning compilers implement the theoretical SOTA (you're probably referring to the 2+ε bound by Buchsbaum et al.)
I also know that scaling laws and the memory wall are soon gonna overpower the currently used heuristics (e.g., sort by size and do best-fit).
Anyways, I'm glad I "met" someone who has struggled against the same problem. Good luck with your research!
Think about the ILP with disjunctions formulation of DSA. It's basically a set of linear equations right? In the case of DNNs, the equations are related: the sizes of the allocations in one layer (in say a CNN) are algebraically a function of the outputs of the previous layer. And so on all the way back to the inputs. So what looks like a set of linear equations in N variables is actually a much smaller set of nonlinear equations in K << N variables.
Okay non-linear equations are hard but that's not actually what I'm getting at - what I'm getting at is the instances of the DSA problem in a production ML pipeline are parametric. So I tried to solve this problem: given a DNN and its parameterized DSA instances, can you do some work offline (to solve "part" of the problem) so that at runtime there's not a lot of work left. And that question/problem/challenge falls into the bucket of FPT.
> Good luck with your research
I changed topics and graduated. No more research for me yay
1. Formulating DSA as ILP doesn't scale. TelaMalloc starts from this fact as motivation.
2. There's no 1-1 mapping between tensors and allocations. Buffer re-use is important.
3. There's room for offline DSA instances as well. IREE's Stream dialect has a related transform (LayoutSlices.cpp).
Anyways, I'm no ML expert. DSA is much more generic than deep learning compilers. I can't wait to graduate myself and never hear the involved keywords again.
it doesn't scale to what? 405B LLMs? no probably not. but i have plots that show not unreasonable solve times for CNNs with ~30k tensors (~10 minutes) using gurobi.
> There's no 1-1 mapping between tensors and allocations. Buffer re-use is important.
yes i'm aware... that's why I made the comment above that you can't pull this trick in e.g., PyTorch.
> 3. There's room for offline DSA instances as well. IREE's Stream dialect has a related transform (LayoutSlices.cpp).
yes again, i'm aware - that's why I made the comment above that IREE is the only place you could pull this trick. LayoutSlices is one place but hooking the allocator in the HAL is simpler if you don't want to fight IREE's various transformations that happen after that.
> DSA is much more generic than deep learning compilers.
yes that's I posted the OR literature first...
> I can't wait to graduate myself and never hear the involved keywords again.
amen
I’ve interviewed with several companies that asked me this specific question [1], including Facebook, ByteDance, LinkedIn, and a particular team at Apple (not my current team). The interviewers, perhaps somewhat optimistically [2], expected a fully working solution. They gave me about 40 minutes—more than the 15 minutes mentioned in the original comment—but I definitely needed the first 10-15 minutes just to get a brute-force solution running. The rest of the time was spent refining the approach and addressing 1-2 additional requirements to pass a set of visible tests.
It was challenging, but not in a traditional engineering sense. It felt more like an ACM competition [3].
Fortunately, programming skills aren’t the only thing companies assess these days. With over a decade of work experience, behavioral (experience-based) interviews now play a larger role in the final hiring decision. That said, depending on who conducts the technical portion of the interview, you could still be rejected if your code doesn’t work.
[1] https://leetcode.com/problems/the-skyline-problem/descriptio...
[2] Them, being so young (<10 YoE), consider LeetCode a panacea
Sorry for asking you (i'm not, just shouting into the ethernet) - when people say they take a few months off to "grind leetcode" do they just go through the problems on that site? When an employer issues a challenge it's going to be exactly worded as when you practiced? like, the potential employer in your experience gave you that URL and said "go"?
In my experience they won't just give you an URL, it'll just be a problem in the style of the ones there. Thing is, once you've done a few of them you'll see that there's only a set of algorithms that usually apply. The setting and input will vary but in the end you can reduce it to a known algorithm or technic so it's more about finding which one fits and can solve the problem
Then again, my lifetime stats on interviewing at Google, measured by interview scores vs eventual offers extended was somewhere between noise and a slightly negative correlation, so I never did figure out why they let me interview at all! (I think I'm too nice in interviews, because I want everyone to succeed, and asking myself "if this person were on my team, would I be as happy to collaborate with them as I would be with Nick? Really?" only goes so far in counteracting that.)
The README even mentions the guillotine algorithm / method that someone else posted (not the same link, but the same method).
At a glance, this feels like a good case for an exact cover algorithm. Would be neat to see how that compares, here.
BTW, when I needed it, I have ported C algorithm from fontstash library to C++: https://github.com/Const-me/nanovg/blob/master/src/FontStash...
Its still my most starred repo. :shrug:
As for packing sprites for games... I remember the fun on very constrained devices where many of the sprites where actually more round than square. So it was about packing both rectangles (for tiles and "rectangle" sprites) and packing circles too. The size of the spritesheet had to be kept small but in memory things were okay'ish (as in: a "round" sprite could be extracted from the spritesheet in its own rectangle).
Thankfully thing is: this can be done with a much more powerful machine than the device the sprite sheet shall eventually be on.
https://kingbird.myphotos.cc/packing/squares_in_squares.html
IE :
Create a number of compositions where you put everything in random locations.
Discard any compositions with overlaps.
Keep the ones with the smallest wasted space or whatever.
Also, this might be a good application for AI.
As far as I can tell, the "Skyline algorithm" is bottom-left with the limitation that created holes can not be packed. This doesn't feel like a packing algorithm as much as it feels like a heuristic to speed up position finding.
The interesting thing I found is that the simple heuristics work pretty well. I actually had to dial back the level of optimization because it took too long for the human packers to duplicate the packing correctly to be able to close the carton.
I had to set it to a level that retained enough wasted space that allowed them quickly find their own solution, but knowing that for sure all of this stuff will fit into carton size X, because saving an extra few dollars in shipping didn't offset the labor dollars to pack it that way.