I would think that the biggest issue would be memory access. In order to increase performance, there may be a need to address/change the fundamental where memory contents are moved from main memory, to cache, to instruction decoder, to instruction execution - which may also require additional data load and stores. Does it pay to revisit the old DEC PDP architecture (separate instruction / data memory)? Could we somehow move from a CPU/Core central architecture to a memory central architecture - with core/cpu that all access that central memory? Just bouncing ideas, because nano circuitry can only be shrunk so much.

@Jerrold: I agree with that, it can resolve the coherence issues for multi-core systems as well. But on other hand, if memory central architecture is used, it will increase the complexity for multicore system design. Though overall, it can be a new paradigm.

The biggest upcoming challenges:

1) dynamic heterogeneity: as the chip density and number of components grows, heat and faults will cause some regions of the chip to behave differently from other regions. For example the processing speed may become locally different, or a component becomes temporarily unavailable. From the global perspective it looks like hardware components come and leave the system dynamically, or change their properties dynamically. Operating systems have never had to deal with this before, so there will be new operating system research needed.

2) faults: as the feature size (gates) becomes smaller, components become more sensitive to cosmic rays, spontaneous quantum discharges etc. Overall the rate of faults will seem to increase as components become smaller, and the cost of fault tolerance via simple redundancy will increase dramatically. A way to keep these costs down could be to accept non-determinism. and start programming with algorithms that tolerate computing error at any level of the programming stack. Again, this is new.

@Raphael: Dynamic heterogeneity seems very interesting, which is ignored by most of the designers. Can task fragmentation (with thermal and inter-core communication overheads considerations) address the problem to some extent?

Regarding fault tolerant programming, it will be a HUGE step to change the SW paradigm. Current SW applications are design without any major HW platform considerations like for traditional single core systems, performance of sequential code is supposed to be linearly increased with clock speed. Here, fault tolerance during the SW design can be considered.

In multi-core architectures, efficient task partitioning and inter-core communication mechanism are the key factors to enhance the performance, which increases the responsibilities of the SW designer. Thus considering the fault tolerance in SW designing and other issues like thermal aware compilation will increase the design complexity a lot. Do you agree?

Though, I agree with all your comments but these are the issues, just came to my mind.

Task fragmentation will offset the problem of dynamic heterogeneity on performance but only assuming that operating systems and especially task *schedulers* are able to react properly to changes in the resource characteristics. To my knowledge we do not have any framework for this yet. Do you know any?

For faults yes of course design complexity is issue #1. But as I said earlier maybe we can alleviate that issue by accepting non-determinism in programming models. We are truly between a rock and a hard place.

Artificial compiler (to mind the gap between SW & HW ).

Reconfiguration CPU/GPU/Cache such that the PEs and cache are connected on demand of application. Further, in the case of fault of PE, it can be isolated from the whole system.

Other models for computing

@Raphael: For network-on-chip platform, there are task fragmentation frameworks. But it might be easier because of the topology. For bus based interconnection platforms like Segbus, task fragmentation may not be that helpful since it does not effect the communication overheads that much.

Can we address the fault tolerance in programming by considering the number of homogeneous core availability? Options are simple:

1. Map the task of failed core to another core with minimum computation load. Here, we may need task fragmentation to minimize the communication overheads.

2. Register contents are saved for application mapped to N cores. In case of a processing core failure, then application partitioned with N-1 cores is mapped and so on till design constraints are met. Though it will introduce overheads to save the instruction set.

Since, fault tolerance is not my major, could you please recommend more suitable solutions.

@Younis: regrading artificial compiler, could you please explain a bit, what parameters should be considered? Like thermal awareness, communication overheads, task partitioning and allocation... I goggled artificial compiler ant it referred to artificial intelligence compiler. Probably you meant that?

Faulty PE has already been addressed and first preference should be to utilize the fault-free resources in faulty PE. As last option, it should be isolated to avoid static power consumption overheads.

@ Latif

Yes, I mean A.I . compiler. In fact, the development of parallel applications are so hard (due to stepping curve). Providing some Computer Aided tools (involve AI compiler) would speed up (perhaps assist and not replace) the development and resources management as the examples you mentioned.

Further study is desired to make the static power dissipation within the limit ( for instance, as an alternative of overclocking which increase the dynamic power dissipation).

Another issue for SW industry is from end user perspective. For example, does the end user agree to use the full computing power in his/her system by a single application? Could the user control the available cores-resources for an application in an easy way?

Implementing large scale quantum computation seems to me to be the greatest challenge in computational methods and technology, and the most potentially fruitful by far. The vast storage and computing abilities enabled by superposition and quidbit coding will enable such systems to exceed current capabilities by many orders of magnitude, and to solve problems that currently literally could not be solved in a billion years. The technical challenges realizing such aspirations present are commensurate with their promise. Canada's would- be quantum computing trailblazer, the D-Wave system, cools a few atoms with vast cryogenic equipment to preserve entanglement. How to scale that up computationally and down resource-wise so we can produce quantum versions of the plethora of classical physics-based devices ranging from Google Glasses to looming exascale high performance computing systems?

beside power consumption the other great challenge of exascale will be the resilience, the fault tolerance.

What should be the considerations while designing an Operating system for quantum computers?

It's difficult to extrapolate considerations on "classical" computer to the designing of an Operating system for quantum computers... I wouldn't dare to.