I've never had success getting it to run either:

    [profiler.cpp:75] Starting profiler thread
    [libcoz.cpp:96] init_coz in progress, do not recurse
    [profiler.h:123] Thread state not found
    Aborted!
      0: /usr/bin/../lib64/coz-profiler/libcoz.so(_ZN8profiler8on_errorEiP9siginfo_tPv+0x6c) [0x7a084dbb274c]
      1: /usr/lib/libc.so.6(+0x3c770) [0x7a084d8ac770]
      2: /usr/lib/libc.so.6(+0x8d32c) [0x7a084d8fd32c]
      3: /usr/lib/libc.so.6(gsignal+0x18) [0x7a084d8ac6c8]
      4: /usr/lib/libc.so.6(abort+0xd7) [0x7a084d8944b8]
      5: /usr/bin/../lib64/coz-profiler/libcoz.so(pthread_create+0x18c) [0x7a084dbaf8ec]
      6: /usr/bin/../lib64/coz-profiler/libcoz.so(_ZN8profiler7startupERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP4lineib+0x208) [0x7a084dbb2fd8]
      7: /usr/bin/../lib64/coz-profiler/libcoz.so(_Z8init_cozv+0xf95) [0x7a084dbaeb25]
      8: /usr/bin/../lib64/coz-profiler/libcoz.so(+0x1a733) [0x7a084dbaf733]
      9: /usr/lib/libc.so.6(+0x25cd0) [0x7a084d895cd0]
      10: /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7a084d895d8a]
      11: target/release/mybin(+0x7b155) [0x556484976155]

I think the concept is interesting, but I haven't been able to actually make it work so it remains a theoretically interesting approach.

What system are you running on? Currently only Linux is supported. I've been running it on Ubuntu LTS.

Obviously from the paths it's Linux. Running on Arch.

Looks to be an open issue FWIW: https://github.com/plasma-umass/coz/issues/180

The project also sees very little meaningful maintenance activity which leads me to believe it failed to get traction for whatever reason / the authors aren't really focused on it (probably grants ran out & they moved onto other things).

Could've been any posix-like tbh.

Yeah the code def needs some love, but itʼs pretty decent given that it'a academic.

> How would this make any difference for a single threaded program?

Coz can slow down individual sections, not only threads. This will show you how your program behaves with specific lines sped up regardless of threads. A modern computer is also a distributed system, so it has the same counter-intuitive performance behaviours, even when just looking at the memory hierarchy.

That still doesn't entirely make sense. If your program is single threaded then whenever your code is running, the program is waiting for your code and speeding it up will speed up the whole program by the same amount.

If you are never doing concurrent work then there will never be any code where a speed up doesn't affect total runtime because it is waiting for some other work. As I understand it that's the gotcha that Coz fixes, but it doesn't apply in single threaded code.

But I have never got it to work so maybe I'm missing something.

Maybe it's just easier t interpret. Sampling profilers can be a bit confusing, and debug info doesn't always work as neatly as you'd like.

You are ignoring that even single threaded code has a lot of sources of concurrency and side-effects; memory/caches, branch prediction, prefetching...

Watch the talk and look at the examples. Most of them are single-threaded; a bad hash-function causing bucket collisions and linear inserts; SQLite using an indirection table, killing speculative execution and code prefetching.

Those two wouldn't really show up in a sampling profiler, because they still take up a tiny amount of time.

Sampling profilers show you where time is spend, Causal profilers show you what performance side effects every line of code has.

I have literally discovered and fixed the "bad hash function" case at work using gperftools. I'll watch the talk again anyway.

Even if it's single thread a program can be concurrent and waiting on same resources.