scalene
bcc
Our great sponsors
scalene | bcc | |
---|---|---|
32 | 69 | |
11,125 | 19,364 | |
1.6% | 2.0% | |
9.3 | 9.2 | |
3 days ago | 7 days ago | |
Python | C | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
scalene
-
Memray – A Memory Profiler for Python
I collected a list of profilers (also memory profilers, also specifically for Python) here: https://github.com/albertz/wiki/blob/master/profiling.md
Currently I actually need a Python memory profiler, because I want to figure out whether there is some memory leak in my application (PyTorch based training script), and where exactly (in this case, it's not a problem of GPU memory, but CPU memory).
I tried Scalene (https://github.com/plasma-umass/scalene), which seems to be powerful, but somehow the output it gives me is not useful at all? It doesn't really give me a flamegraph, or a list of the top lines with memory allocations, but instead it gives me a listing of all source code lines, and prints some (very sparse) information on each line. So I need to search through that listing now by hand to find the spots? Maybe I just don't know how to use it properly.
I tried Memray, but first ran into an issue (https://github.com/bloomberg/memray/issues/212), but after using some workaround, it worked now. I get a flamegraph out, but it doesn't really seem accurate? After a while, there don't seem to be any new memory allocations at all anymore, and I don't quite trust that this is correct.
There is also Austin (https://github.com/P403n1x87/austin), which I also wanted to try (have not yet).
Somehow this experience so far was very disappointing.
(Side node, I debugged some very strange memory allocation behavior of Python before, where all local variables were kept around after an exception, even though I made sure there is no reference anymore to the exception object, to the traceback, etc, and I even called frame.clear() for all frames to really clear it. It turns out, frame.f_locals will create another copy of all the local variables, and the exception object and all the locals in the other frame still stay alive until you access frame.f_locals again. At that point, it will sync the f_locals again with the real (fast) locals, and then it can finally free everything. It was quite annoying to find the source of this problem and to find workarounds for it. https://github.com/python/cpython/issues/113939)
- Scalene: A high-performance CPU GPU and memory profiler for Python
- Scalene: A high-performance, CPU, GPU, and memory profiler for Python
-
How can I find out why my python is so slow?
Use this my fren: https://github.com/plasma-umass/scalene
-
Making Python 100x faster with less than 100 lines of Rust
You should take a look at Scalene - it's even better.
-
Blog Post: Making Python 100x faster with less than 100 lines of Rust
I like seeing another Python profiler. The one I've been playing with is Scalene (GitHub). It does some fun things related to letting you see how much things are moving across the system Python memory boundary.
-
Cum as putea sa imbunatatesc timpul de rulare al pitonului?
Ai vazut "Python Performance Matters" by Emery Berger (Strange Loop 2022)? E in principiu o prezentare si demo cu Scalene.
- Scalene - A Python CPU/GPU/memory profiler with optimization proposals
- Scalene: A Python CPU/GPU/memory profiler with optimization proposals
-
OpenAI might be training its AI technology to replace some software engineers, report says
I tried out some features of machine learning models suggesting optimisations on code profiled by scalene and pretty much all of them would make the code less efficient, both time and memory wise. I am not worried. The devil is in the details and ML will not replace all of us anytime soon
bcc
-
eBPF Documentary
One of the big wins is not so much “build and run your own stuff” but there are very nice low-cost (in terms of compute) performance utilities built on eBPF
https://github.com/iovisor/bcc
There are so many utilities in that list; there’s a diagram midway down the readme which tries to help show their uses. bcc-tools should be available in any distro.
Also, Brendan Gregg does a ton of performance stuff that is worth knowing about if you check out his other work. Not eBPF only. Flame graphs are useful.
- Bpftop: Streamlining eBPF performance optimization
-
eBPF Tutorial by Example 16: Monitoring Memory Leaks
Reference: https://github.com/iovisor/bcc/blob/master/libbpf-tools/memleak.c
- eBPF Tutorial by Example 9: Capturing Scheduling Latency and Recording as Histogram
-
Uprobes Siblings - Capturing HTTPS Traffic: A Rust and eBPF Odyssey
In this article, we'll build a basic version of an HTTPS sniffer, inspired by bcc-sslsniff.py, but we'll use Rust and Aya. We're going to demonstrate the capabilities of uprobes by employing uprobe and uretprobe along with familiar maps like PerCpuArray, HashMap, and PerEventArray. This will be a straightforward example to help us explore how uprobes function.
-
Issue XDP_REDIRECT on other interface in the same namespace
As xpd program I am using the BCC example xdp_redirect_map.py in skb mode as my NIC does not support native mode, attaching the program to veth2 and a dummy function to veth3
- Linux runtime security agent powered by eBPF
- eBPF Practical Tutorial: Capturing SSL/TLS Plain Text Data Using uprobe
-
PF bug in macOS Sonoma release candidate
In Linux you can use eBPF. See https://github.com/iovisor/bcc for an easy way to write eBPF, or look for something in the tools/ dir that does what you want. You distro might have these packaged in bcc-tools or similar.
-
eBPF Verification Is Untenable
The whole BPF verifier and development process is so botched, it's ridiculous. It's like maintainers decided to make this as hard as possible out of pettiness and "they have to use C APIs instead" or something.
- Loading an eBPF module without the CAP_BPF (and in some cases without the CAP_NET_ADMIN which you need for XDP) capabilities will generate a "unknown/invalid memory access" error which is super useless as an error message.
- In my personal opinion a bytecode format for both little endian (bpfel) and big endian (bpfeb) machines is kinda unnecessary. I mean, it's a virtual bytecode format for a reason, right!?
- Compiling eBPF via clang to the bpf bytecode format without debug symbols will make every following error message down the line utterly useless. Took me a while to figure out what "unknown scalar" really means. If you forget that "-g" flag you're totally fucked.
- Anything pointer related that eBPF verifier itself doesn't support will lead to "unknown scalar" errors which are actually out of bounds errors most of the time (e.g. have to use if pointer < size(packet) around it), which only happen in the verification process and can only be shown using the bpftool. If you miss them, good luck getting a better error message out of the kernel while loading the module.
- The bpftool maintainer is kind of unfriendly, he's telling you to read a book about the bytecode format if your code doesn't compile and you're asking about examples on how to use pointers inside a BPF codebase because it seems to enforce specific rules in terms of what kind of method (__always_static) are allowed to modify or allocate memory. There's a lot of limitations that are documented _nowhere_ on the internet, and seemingly all developers are supposed to know them by reading the bpftool codebase itself!? Who's the audience for using the bpftool then? Developers of the bpftool itself?
- The BCC tools (bpf compiler collection) are still using examples that can't compile on an up-to-date kernel. [1] If you don't have the old headers, you'll find a lot of issues that show you the specific git hash where the "bpf-helpers.h" file was still inside the kernel codebase.
- The libbpf repo contain also examples that won't compile. Especially the xdp related ones [2]
- There's also an ongoing migration of all projects (?) to xdp-tools, which seems to be redundant in terms of bpf related topics, but also has only a couple examples that somehow work [3]
- Literally the only userspace eBPF generation framework that worked outside a super outdated enterprise linux environment is the cilium ebpf project [4], but only because they're using the old "bpf-helpers.h" file that are meanwhile removed from the kernel itself. [5] They're also incomplete for things like the new "__u128" and "__bpf_helper_methods" syntax which are sometimes missing.
- The only working examples that can also be used for reference on "what's available" in terms of eBPF and kernel userspace APIs is a forked repo of the bootlin project [6] which literally taught me how to use eBPF in practice.
- All other (official?) examples show you how to make a bpf_printk call, but _none_ of them show you how to even interact with bpf maps (whose syntax changed like 5 times over the course of the last years, and 4 of them don't run through the verifier, obviously). They're also somewhat documented in the wiki of the libbpf project, without further explanation on why or what [7]. Without that bootlin repo I still would have no idea other than how to make a print inside a "kretprobe". Anything more advanced is totally undocumented.
- OpenSnitch even has a workflow that copies their own codebase inside the kernel codebase, just to make it compile - because all other ways are too redundant or too broken. Not kidding you. [8]
Note that none of any BPF related projects uses any kind of reliable version scheme, and none of those project uses anything "modern" like conan (or whatever) as a package manager. Because that would have been too easy to use, and too easy on documenting on what breaks when. /s
Overall I have to say, BPF was the worst development experience I ever had. Writing a kernel module is _easier_ than writing a BPF module, because then you have at least reliable tooling. In the BPF world, anything will and can break at any unpredictable moment. If you compare that to the experience of other development environments like say, JVM or even the JS world, where debuggers that interact with JIT compilers are the norm, well ... then you've successfully been transferred back to the PTSD moments of the 90s.
Honestly I don't know how people can use BPF and say "yeah this has been a great experience and I love it" and not realize how broken the tooling is on every damn level.
I totally recommend reading the book [9] and watching the YouTube videos of Liz Rice [10]. They're awesome, and they show you how to tackle some of the problems I mentioned. I think that without her work, BPF would have had zero chance of success.
What's missing in the BPF world is definitely better tooling, better error messages (e.g. "did you forget to do this?" or even "unexpected statement" would be sooooo much better than the current state), and an easier way to debug an eBPF program. Documentation on what's available and what is not is also necessary, because it's impossible to find out right now. If I am not allowed to use pointers or whatever, then say so in the beginning.
[1] https://github.com/iovisor/bcc
[2] https://github.com/libbpf/libbpf
[3] https://github.com/xdp-project/xdp-tools
[4] https://github.com/cilium/ebpf/
[5] https://github.com/cilium/ebpf/tree/master/examples/headers
[6] https://elixir.bootlin.com/linux/latest/source/tools/testing...
[7] https://github.com/libbpf/libbpf/wiki/Libbpf-1.0-migration-g...
[8] https://github.com/evilsocket/opensnitch/blob/master/ebpf_pr...
[9] https://isovalent.com/learning-ebpf/
[10] (e.g.) https://www.youtube.com/watch?v=L3_AOFSNKK8
What are some alternatives?
flask-profiler - a flask profiler which watches endpoint calls and tries to make some analysis.
libbpf - Automated upstream mirror for libbpf stand-alone build.
palanteer - Visual Python and C++ nanosecond profiler, logger, tests enabler
bpftrace - High-level tracing language for Linux eBPF [Moved to: https://github.com/bpftrace/bpftrace]
pytest-austin - Python Performance Testing with Austin
ebpf-for-windows - eBPF implementation that runs on top of Windows
memray - Memray is a memory profiler for Python
zfs - OpenZFS on Linux and FreeBSD
pyshader - Write modern GPU shaders in Python!
linux - Linux kernel source tree
viztracer - VizTracer is a low-overhead logging/debugging/profiling tool that can trace and visualize your python code execution.
flamegraph - Easy flamegraphs for Rust projects and everything else, without Perl or pipes <3