Edit Question - KnowledgeHub

Title Body

Whilst learning the "assembler language" (in linux on a x86 architecture using the GNU as assembler), one of the aha moments was the possibility of using system calls . These system calls come in very handy and are sometimes even necessary as your program runs in user-space . However system calls are rather expensive in terms of performance as they require an interrupt (and of course a system call) which means that a context switch must be made from your current active program in user-space to the system running in kernel-space. The point I want to make is this: I'm currently implementing a compiler (for a university project) and one of the extra features I wanted to add is the support for multi-threaded code in order to enhance the performance of the compiled program. Because some of the multi-threaded code will be automatically generated by the compiler itself, this will almost guarantee that there will be really tiny bits of multi-threaded code in it as well. In order to gain a performance win, I must be sure that using threads will make this happen. My fear however is that, in order to use threading, I must make system calls and the necessary interrupts. The tiny little (auto-generated) threads will therefore be highly affected by the time it takes to make these system calls, which could even lead to a performance loss... my question is therefore twofold (with an extra bonus question underneath it): Is it possible to write assembler code which can run multiple threads simultaneously on multiple cores at once, without the need of system calls? Will I get a performance gain if I have really tiny threads (tiny as in the total execut

Tags (comma-separated) Cancel