Toy example cannot reproduce the plots presented in the paper

[yifan19]

I used an aws instance c4.2xlarge (8 vcores) and followed the README.md requirement to build everything
and ran

for i in `seq 100`; do sudo coz  run --- ./coz/benchmarks/toy/toy; done

which generates something like the following plot

profile3.txt

[kwinata]

I also got same issue, mine likely because for some reason, for thread created, the load is equally spread across multiple cores instead of only 2 cores:

If I set some CPU affinity for the thread, the result is quite consistent (in my experiment the ratio is 15:20 instead of 19:20)

Here is the code using CPU affinity (partially from chatgpt)

#include <thread>
#include <pthread.h>
#include <sched.h>
#include <iostream>
#include <coz.h>

volatile size_t x;
char padding[1024];
volatile size_t y;

long long mod = (long long)(1e9 + 7);

void set_affinity(std::thread &t, int core_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);

    int rc = pthread_setaffinity_np(t.native_handle(), sizeof(cpu_set_t), &cpuset);
    if (rc != 0) {
        std::cerr << "Error setting affinity for thread: " << rc << "\n";
    }
}

void a() {
    long long i = 1;
    for (x = 1; x <= 2000000; x++) {
        i = (i * x) % mod;
    }
}

void b() {
    long long i = 1;
    for (y = 1; y <= 1500000; y++) {
        i = (i * y) % mod;
    }
}

int main() {
    for (int i = 0; i < 500; i++) {
        std::thread a_thread(a);
        set_affinity(a_thread, 0); // Bind `a_thread` to core 0

        std::thread b_thread(b);
        set_affinity(b_thread, 1); // Bind `b_thread` to core 1

        a_thread.join();
        b_thread.join();
	COZ_PROGRESS;
    }

    return 0;
}

I compile using clang++ -pthread -g -gdwarf-3 -ldl -O0 toy/toy_affinity.cpp

And can get the following result:

I'm sure this is not the intended usage of coz 😂 but hope that helps answer your query

[TimHuDi]

@yifan19， I get the similar plot as you. The toy.cpp:21 is a flat line, but toy.cpp:17 is a steep upward slopes. I think it's make sense, because coz may not give a accurate pridiction of the program speedup , it can only give a relative optimization impact. Because the virtual speedup is relative to the sample period, not to the original selected line.
Do you have any idea about this?