111–120 of 375 posts
I haven't used a non-libc malloc before but I suspect the same applies.
Earlier quoted context omitted.
Sorry, I didn't mean symbols, I meant optimization level. Hilarious that they have symbols stripped, but still outclassed. Love to see why they wouldn't have more optimizations. I'm assuming this isn't the case for more packages? Feels too good.
Debug symbols do not need to be paged in so shouldn’t make much/any difference. Compiling with -O3 can increase code size a lot due to inlining, which can be a little bad.
(Well, rebuilding them with a different allocator that benchmarks well on their specific workflow.)
-march=native + mimalloc (or jemalloc) should be sufficient without causing significant undefined behavior like -O3 or most extra optimization related compiler arguments.
Earlier quoted context omitted.
Sorry, I didn't mean symbols, I meant optimization level. Hilarious that they have symbols stripped, but still outclassed. Love to see why they wouldn't have more optimizations. I'm assuming this isn't the case for more packages? Feels too good.
> Hilarious that they have symbols stripped, but still outclassed. Debug symbols have 0 runtime penalty, just storage. They're just another section of the binary, referenced by debuggers, and which the loader skips. In any case, all distros break out the symbols into separate files so that they can have their (storage) cake and (debug) eat it too.
Earlier quoted context omitted.
Sorry, I didn't mean symbols, I meant optimization level. Hilarious that they have symbols stripped, but still outclassed. Love to see why they wouldn't have more optimizations. I'm assuming this isn't the case for more packages? Feels too good.
Ubuntu is still building for CPUs with the x86-64-v1 feature set. On experimental images built for x86-64-v3 (roughly the feature set of 10 year old CPUs, a bit newer on low-power CPUs) they have observed 60% improvement on some benchmarks (and much less in some others). Some distros have switched to -v3, Ubuntu is still holding out to support older hardware. The author is compiling to the actual feature set of their…
Not sure where I got that idea, though. :(. Will have to look into that later.
Misleading title, it's 90% of the faster time. It's about 45% faster. It's actually a little bit interesting, if you are interested in how we use language. You could argue that now you now get 90% more work done in the same amount of time, and that would align with other 'speed' units that we commonly use (miles per hour, words per minute, bits per second). However, the convention in computer performance is to measur…
Earlier quoted context omitted.
Sorry, I didn't mean symbols, I meant optimization level. Hilarious that they have symbols stripped, but still outclassed. Love to see why they wouldn't have more optimizations. I'm assuming this isn't the case for more packages? Feels too good.
Debug symbols do not need to be paged in so shouldn’t make much/any difference. Compiling with -O3 can increase code size a lot due to inlining, which can be a little bad.
And understood a little on -O3 possibly increasing code size. I had thought that was more of a concern for tight environments than for most systems? Of course, I'd have assumed that -march=native would be more impactful, but the post indicates otherwise.
I said in a top level, but it seems the allocator makes the biggest impact for this application? Would be interesting to see which applications should use different allocators. Would be amazing to see a system where the more likely optimal allocator was default for different applications, based on their typical allocation patterns.
apt-get source jq
You'll get a result much closer to the upstream Ubuntu, as opposed to getting lots of weird errors and misalignments.