HenningTimm

Memory profiling Rust code with heaptrack in 2019

I recently ran into a classic case of "our code is using way more memory than it should". So I took my first dive into memory profiling Rust code. I read several posts about this, including the following

• KodrAus' gist on profiling rust
• This reddit thread
• Brendan D. Gregg's post about memory flamegraphs
• Bradlee Speice's A Case Study in Heaptrack

charlie-collard

import requests
import praw
import logging
import time
import random
import schedule
import pickle
import sys
from datetime import datetime, timedelta

rygorous

why doesn't radfft support AVX on PC?

So there's two separate issues here: using instructions added in AVX and using 256-bit wide vectors. The former turns out to be much easier than the latter for our use case.

Problem number 1 was that you positively need to put AVX code in a separate file with different compiler settings (/arch:AVX for VC++, -mavx for GCC/Clang) that make all SSE code emitted also use VEX encoding, and at the time radfft was written there was no way in CDep to set compiler flags for just one file, just for the overall build.

[There's the GCC "target" annotations on individual funcs, which in principle fix this, but I ran into nasty problems with this for several compiler versions, and VC++ has no equivalent, so we're not currently using that and just sticking with different compilation units.]

The other issue is to do with CPU power management.

tomaka

Let's take the first example from the Rust generators RFC:

#[async]
fn print_lines() -> io::Result<()> {
    let addr = "127.0.0.1:8080".parse().unwrap();
    let tcp = await!(TcpStream::connect(&addr))?;
    ...
}

KodrAus

Profiling performance

Using perf:

$ perf record -g binary
$ perf script | stackcollapse-perf.pl | rust-unmangle | flamegraph.pl > flame.svg

NOTE: See @GabrielMajeri's comments below about the -g option.

rygorous

Why do compilers even bother with exploiting undefinedness signed overflow? And what are those
mysterious cases where it helps?

A lot of people (myself included) are against transforms that aggressively exploit undefined behavior, but
I think it's useful to know what compiler writers are accomplishing by this.

TL;DR: C doesn't work very well if int!=register width, but (for backwards compat) int is 32-bit on all
major 64-bit targets, and this causes quite hairy problems for code generation and optimization in some
fairly common cases. The signed overflow UB exploitation is an attempt to work around this.

detomon

SSE Intrinsic Cheat Sheet (SSE3)

Load and Store

__m128 _mm_load_ps (float * a)
{

sr105

#! /bin/bash
# Description: show dependency tree
# Author: damphat

if [ $# -lt 1 ]; then
	echo 'Usage: apt-rdepends-tree [-r] <package>'
	echo 'Required packages: apt-rdepends'
	exit 1  
fi

shizmob

#!/bin/sh
downpomf="https://a.pomf.cat/"
uppomf="https://pomf.cat/upload.php"

if test $# -lt 1 ; then
    echo "Usage: `basename $0` FILE [FILE...]"
    exit 1
fi

set=

damphat

#! /bin/bash
# Description: show dependency tree
# Author: damphat

if [ $# != 1 ]; then
	echo 'Usage: apt-rdepends-tree <package>'
	echo 'Required packages: apt-rdepends'
	exit 1  
fi