/dpt/ - Daily Programming Thread

If you didn't have internships, you basically have no choice but to do freelance until you get 2 years of experience minimum. Meanwhile, keep applying for jobs, but you'll keep being rejected.

Startups with underpaid entry level positions are also possible.

Around here, they haven't been possible for years. They still demand years of experience on top of underpaying.

basically just copying go, which is probably pretty smart.

Would make it res.write instead of res.print though.

Thanks for the suggestion!

#include
#include

void work(int *n) {
for (int i = 0; i < 10000; i++)
(*n)++;
}

int main()
{
int a = 0;
int b = 0;
int c = 0;
int d = 0;

std::thread thread_a(work, &a);
std::thread thread_b(work, &b);
std::thread thread_c(work, &c);
std::thread thread_d(work, &d);

thread_a.join();
thread_b.join();
thread_c.join();
thread_d.join();

std::printf("%d\n%d\n%d\n%d\n", a, b, c, d);
}

Why does this work correctly and return 10000 for each variable?
Shouldn't the threads fuck each other up because they are working on the same cache line?
If there is no problem here in the first place, why does std::atomic kill performance in these scenarios?

>Shouldn't the threads fuck each other up because they are working on the same cache line?
No, and they may not be.

>If there is no problem here in the first place, why does std::atomic kill performance in these scenarios?
Because this situation is embarrassingly parallel - none of the data is involved with each other, therefore nothing will affect the memory of another variable from an abstract machine standpoint.

I don't know where you intended to put std::atomic in this, but that would demand that threads wait for each other during access, which isn't necessary at all here. That extra wait will definitely hurt performance.

>If you didn't have internships, you basically have no choice but to do freelance until you get 2 years of experience minimum. Meanwhile, keep applying for jobs, but you'll keep being rejected.
2 internships and a contract job are under my belt. Will try to keep applying and not lose my sanity.
>Startups with underpaid entry level positions are also possible.
They are, I’ve seen them have twice as many applicants though as of late

no idea, but I wonder what happens if you move your variables off the stack. Like instead of four ints, do int abcd = new int[4]

Reminding anons to use github.com/friendlyanon/cmake-init when creating new C++ and C projects!

Cache is localized. Just like how you don't actually have just a handful of registers but rather hundreds of them and the CPU masks those you (bad goy) aren't allowed to touch from your thread.

>2 internships and a contract job are under my belt.
Then you have a huge leg up over the competition, the only true hurdle on your path is the absolute state of the job market is all.

what are you trying to do?
because this is what you are actually doing: working with 4 independent threads, each thread uses its own integer variable. data is not shared between threads, one thread does not acess the variable of another thread. there are no race conditions.
you use std::atomic when there is shared data between threads.

i still disagree with not putting a CMakeLists.txt file in the source directory but you are entitled to your opinion

The idea is that while they are not accessing the same data, they are accessing the same cache line, because the data is adjacent in memory.
So if thread_a writes its cache line back into memory it should write a wrong value for all other variables because it has no reason to know about those increments.

thread local storage, I think

thread_a writes 4 bytes at address 0x0000, thread_b writes 4 bytes at address 0x0100. why would one affect the other?