A work whine

[flexagon]

Weh. You know what sucks? Spending all week looking at an obscure multithready performance bug, that's what sucks. I suppose it's good that I now have a better understanding of the heap (there's one perprocess) and stacks (there's one per thread). I've also learned that you don't REALLY know for shit about your thread situation until you're running on a multi-CPU machine. But I don't know what is being synchronized on and thus ruining our scalability... no idea. :(

And yes! I would like some cheese with this. Goddamn it.

(I'm glad it's the weekend, by the way. I get to write a story about a transgression, for the writing class, but I found out this was the assignment only after I triple-promised myself to write a clean story this time. So I was like "Transgression! Woohoo, SEX WITH DEAD PEOPLE no wait I said I wouldn't do that." Ohhhhh well.)

Comments

Re: yay for stacks and heaps

[flexagon]

As far as I can tell (fresh news as of today's stack traces) it's all about threads waiting for a mutex type lock when they allocate and deallocate memory. HLM thinks the entire heap is probably synchronized. I guess the thing to do is check that method, see what's being declared on the heap and see if I can get it stackified.

I don't know of any other implications. But then I didn't know any of this stuff until late last week, so I'm sure there's a lot more I don't know.

In Java everything's on the heap and you still don't have to worry about memory leaks. :b Yayyyyyyyy GARBAGE COLLECTION!

Garbage collection scares me.

[jg26.livejournal.com]

I guess I need to read more about it. I just feel like it should be the responsibility of the developer, not the language, to worry about memory deallocation. How does an application "know" when you're done with some data structure? When you tell it it's done with it, that's when. ;) Yes, you may be immune to memory leaks, but it seems like you've lost some optimization control over your own code. This might just fit into the criticism of higher level languages, like java, that they are chronically slow & unoptimizable.

Re: Garbage collection scares me.

[flexagon]

Well, a lot of the details are in that book of mine you have. Chapter 8, I think. :)

I have the opposite inclination. Memory management is something where there's a LOT of human error, and bugs can take forever to find. A program is much better at doing the necessary reference counting (or whatever other method) to see when something's no longer being referred to. I think others must agree with me, given just how many advances in C++ have led to more programmatic management of memory... I'm thinking STL, autopointers, COM.

You're right about losing some control though. My optimal language would have garbage collection, but it really would be forced to run when you asked it to. You should also be able to call the garbage collector on an object explicitly (it could still protect you by throwing an exception when there are still other references to that object).