View unanswered posts | View active topics It is currently Thu Jan 23, 2020 6:29 pm

Reply to topic  [ 12 posts ]  Go to page Previous  1, 2
Author Message
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15344
Location: Home sweet home!
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 :-)


_________________ - where Open Source means Open Source, and Free means Freedom - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!

Sun Apr 26, 2009 12:21 am
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Mon Mar 31, 2008 12:47 am
Posts: 568
Location: New Zealand, land of the long white burnout
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.

Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82

Sun Apr 26, 2009 9:11 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 12 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.