Products > Computers

Language/ compiler and the most apropriate CPU to run the application.

<< < (5/6) > >>

westfw:

--- Quote ---Is it reasonable to expect that the development platform/language/ libraries used in writing an application will result in a preference for a  CPU in terms of number of cores/ threads etc?
--- End quote ---
I would think that it would normally work the other way around.  Given a particular target CPU (or class thereof), and a particular problem, I'd pick the platform/language/libraries.  In general, parallelization for multiple cores is not handled very automatically, except maybe for particular sub-problems.  A fortran compiler might do a fine job of parallelizing big matrix math problems, but you probably wouldn't want to use it for computer vision or machine learning...

Siwastaja:

--- Quote from: T3sl4co1l on June 19, 2019, 03:57:10 pm ---Threads are a hardware construct on some processors (e.g. HyperThreading), but mostly they're an OS construct.  So mentioning threads at all, presupposes an OS that provides them, and a CPU that can run that OS in turn.  Historically, this is usually a 32-bit+ CPU with MMU.  80386 and Cortex M4 for example.

--- End quote ---

Do note that threading is fundamentally not that different compared to what you do with interrupts, even with the simplest 8-bit PIC or AVR (or when you wrote interrupt handlers on a PC in DOS era). Same constraints about unpredictable "parallel" execution and protecting state with mutex-like structures apply. The term "thread" is not used here, but it's very close, and same mental models work.

tggzzz:

--- Quote from: Siwastaja on June 23, 2019, 03:45:14 pm ---
--- Quote from: T3sl4co1l on June 19, 2019, 03:57:10 pm ---Threads are a hardware construct on some processors (e.g. HyperThreading), but mostly they're an OS construct.  So mentioning threads at all, presupposes an OS that provides them, and a CPU that can run that OS in turn.  Historically, this is usually a 32-bit+ CPU with MMU.  80386 and Cortex M4 for example.

--- End quote ---

Do note that threading is fundamentally not that different compared to what you do with interrupts, even with the simplest 8-bit PIC or AVR (or when you wrote interrupt handlers on a PC in DOS era). Same constraints about unpredictable "parallel" execution and protecting state with mutex-like structures apply. The term "thread" is not used here, but it's very close, and same mental models work.

--- End quote ---

Very true, and it is surprising how few people realise that.

I suspect it is a combination of only seeing things from a hardware point of view, plus (most) languages only having interrupt processing as a bolt-on afterthought.

NorthGuy:

--- Quote from: Siwastaja on June 23, 2019, 03:45:14 pm ---Do note that threading is fundamentally not that different compared to what you do with interrupts, even with the simplest 8-bit PIC or AVR (or when you wrote interrupt handlers on a PC in DOS era). Same constraints about unpredictable "parallel" execution and protecting state with mutex-like structures apply. The term "thread" is not used here, but it's very close, and same mental models work.

--- End quote ---

It's worse. On PIC and AVR, the ISR code can interrupt the "main" code by not wise versa. With a free-threading OS, there's no telling - everything can get interrupted at any time.

T3sl4co1l:
Indeed.  Interrupts are often discussed in terms of "main() thread" vs "interrupt thread"!

You can make a task switcher in an interrupt and make a rudimentary RTOS yourself.  But again, overhead makes it prohibitive -- say for AVR, having so many registers and so little RAM, you could maybe hold a hundred threads with no free RAM left to use!

The lack of thread-safe IO drivers is the other side of that, too.  Ideally you'd abstract away IO registers via device drivers, with access explicitly through API calls including thread-locked access (e.g., how opening COM1 or dev/rtty1 for writing, blocks another thread from also locking it).  And it would be nice to enforce that with privilege levels (restricts IO, RAM accesses) and an MMU (restricts and remaps memory spaces).  And even nicer to have the extra CPU power to be able to do these things without totally bogging down.  And...

:)

Tim

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version