DIYEFI.org Forum

tobz wrote:We're both right, pretty much.

Again, I wasn't arguing, just adding in another angle as I thought you weren't 100% clear.

having 4 threads on a quad-core (non-hyperthreaded) will always be as fast, most likely faster, than having 8 or 16 threads. This is where staying close to core count for thread count is good.

Agreed, there is no point dividing a single task further than the number of logical cores you have. Again though, if you have an imbalance of load in your tasks and less cores than tasks, then it could easily be beneficial to split it further anyway.

I'd like to see some metrics on context switching and cost (at least on a solid kernel implementation). Years ago I used to encode mp3s in parallel - 100's at a time on a single core 350mhz k6-II and it was still usable under that load even to the point of still being able to rip a cd with cdparanoia at the same time. I know that doing them sequentially would have been faster (for cpu, let alone fragmented disk IO), but it certainly wasn't a huge difference anyway.

Python has nothing like this as far as I know

I don't think it parallelises, but check out psyco for phthon speed increases.

so careful initial design and testing will ultimately lead to the best performance. In reality, though, what needs to be done is very simple, it just needs to be designed properly from the start. :)

Agreed 100%

I'm actually working on a flowchart/UML diagram/whatever-you-want-call-it of how I think the software should look. I actually haven't even looked at the code, because I want to see how close I come to what exists, and I don't want the existing design to influence how I think it should be designed. Hopefully my thoughts can give a fresh insight to things that could be done differently/better.

Excellent!! I can't wait to see it and see what Aaron has to say about it vs. what he has :-)

Fred.

Yeah I like the idea of seeing a flowchart too

I won't comment on how the Tuner threading currently works to help keep it unbiased.