In the future, processors may work as Lego toys, then you can build heterogenous systems more conveniently.
dsaksena
I think to do this the operating system is in the best position and it probably would provide a system call with the thread_fork utility in order to know the preference of the user as to which core should be preferred to schedule this thread on.
Truly an interesting problem I'd love to try solving it someday.
In case we wanna avoid system calls for defining preferences, we could maybe even look at applying machine learning algorithm to see what kind of task could be scheduled on which core, would be more useful on a domain specific machine.
afa4
I think The last point in this slide is the most crucial. The right mixture of resources will heavily depend on the kind of workload that you will be running on the system.
zhanpenf
This wiki page "http://en.wikipedia.org/wiki/Heterogeneous_computing" introduces some other challenges that heterogeneous system has, including different instruction sets, different application binary interfaces, different memory interfaces, and etc..
jazzbass
These slides from 15740 are very interesting. They talk about multiple challenges in exploiting heterogeneous architectures.
They also talk about problems with energy. For example, they mention that virtual machines consume up to 40% extra computation time and energy. The JVM consumes about 37%, due to garbage collection, JIT and executing untouched instructions via the interpreter. They describe a paper that noticed that the GC is very memory-bound, therefore it is a great candidate to be scheduled on low-power cores. The JIT is not as memory-bound, but it is embarrassingly parallel, therefore it is a good candidate to be scheduled on many low-power cores.
yuel1
I believe if we ever get easy to program FPGAs they will aid a great deal in providing flexibility in our computing resources. For different workloads the FPGA can be configured to have different compute resources. The main challenges these days is FPGAs are hard to program, the synthesis is very compute intensive (not to mention the software to do it is very expensive), and also the fact that FPGAs are not as dense in terms of functionality per unit area as ASICs.
In the future, processors may work as Lego toys, then you can build heterogenous systems more conveniently.
I think to do this the operating system is in the best position and it probably would provide a system call with the thread_fork utility in order to know the preference of the user as to which core should be preferred to schedule this thread on.
Truly an interesting problem I'd love to try solving it someday.
In case we wanna avoid system calls for defining preferences, we could maybe even look at applying machine learning algorithm to see what kind of task could be scheduled on which core, would be more useful on a domain specific machine.
I think The last point in this slide is the most crucial. The right mixture of resources will heavily depend on the kind of workload that you will be running on the system.
This wiki page "http://en.wikipedia.org/wiki/Heterogeneous_computing" introduces some other challenges that heterogeneous system has, including different instruction sets, different application binary interfaces, different memory interfaces, and etc..
These slides from 15740 are very interesting. They talk about multiple challenges in exploiting heterogeneous architectures.
They also talk about problems with energy. For example, they mention that virtual machines consume up to 40% extra computation time and energy. The JVM consumes about 37%, due to garbage collection, JIT and executing untouched instructions via the interpreter. They describe a paper that noticed that the GC is very memory-bound, therefore it is a great candidate to be scheduled on low-power cores. The JIT is not as memory-bound, but it is embarrassingly parallel, therefore it is a good candidate to be scheduled on many low-power cores.
I believe if we ever get easy to program FPGAs they will aid a great deal in providing flexibility in our computing resources. For different workloads the FPGA can be configured to have different compute resources. The main challenges these days is FPGAs are hard to program, the synthesis is very compute intensive (not to mention the software to do it is very expensive), and also the fact that FPGAs are not as dense in terms of functionality per unit area as ASICs.