что такое различие между Супермасштабированием и конвейерной обработкой?

A long time ago, CPUs executed only one machine instruction at a time. Only when it was completely finished did the CPU fetch the next instruction from memory (or, later, the instruction cache).

Eventually, someone noticed that this meant that most of a CPU did nothing most of the time, since there were several execution subunits (such as the instruction decoder, the integer arithmetic unit, and FP arithmetic unit, etc.) and executing an instruction kept only one of them busy at a time.

Thus, "simple" pipelining was born: once one instruction was done decoding and went on towards the next execution subunit, why not already fetch and decode the next instruction? If you had 10 such "stages", then by having each stage process a different instruction you could theoretically increase the instruction throughput tenfold without increasing the CPU clock at all! Of course, this only works flawlessly when there are no conditional jumps in the code (this led to a lot of extra effort to handle conditional jumps specially).

Later, with Moore's law continuing to be correct for longer than expected, CPU makers found themselves with ever more transistors to make use of and thought "why have only one of each execution subunit?". Thus, superscalar CPUs with multiple execution subunits able to do the same thing in parallel were born, and CPU designs became much, much more complex to distribute instructions across these fully parallel units while ensuring the results were the same as if the instructions had been executed sequentially.

Pipelining is what a car company does in the manufacturing of their cars. They break down the process of putting together a car into stages and perform the different stages at different points along an assembly line done by different people. The net result is that the car is manufactured at exactly the speed of the slowest stage alone.

In CPUs the pipelining process is exactly the same. An "instruction" is broken down into various stages of execution, usually something like 1. fetch instruction, 2. fetch operands (registers or memory values that are read), 2. perform computation, 3. write results (to memory or registers). The slowest of this might be the computation part, in which case the overall throughput speed of the instructions through this pipeline is just the speed of the computation part (as if the other parts were "free".)

Super-scalar in microprocessors refers to the ability to run several instructions from a single execution stream at once in parallel. So if a car company ran two assembly lines then obviously they could produce twice as many cars. But if the process of putting a serial number on the car was at the last stage and had to be done by a single person, then they would have to alternate between the two pipelines and guarantee that they could get each done in half the time of the slowest stage in order to avoid becoming the slowest stage themselves.

Super-scalar in microprocessors is similar but usually has far more restrictions. So the instruction fetch stage will typically produce more than one instruction during its stage -- this is what makes super-scalar in microprocessors possible. There would then be two fetch stages, two execution stages, and two write back stages. This obviously generalizes to more than just two pipelines.

This is all fine and dandy but from the perspective of sound execution both techniques could lead to problems if done blindly. For correct execution of a program, it is assumed that the instructions are executed completely one after another in order. If two sequential instructions have inter-dependent calculations or use the same registers then there can be a problem, The later instruction needs to wait for the write back of the previous instruction to complete before it can perform the operand fetch stage. Thus you need to stall the second instruction by two stages before it is executed, which defeats the purpose of what was gained by these techniques in the first place.

There are many techniques use to reduce the problem of needing to stall that are a bit complicated to describe but I will list them: 1. register forwarding, (also store to load forwarding) 2. register renaming, 3. score-boarding, 4. out-of-order execution. 5. Speculative execution with rollback (and retirement) All modern CPUs use pretty much all these techniques to implement super-scalar and pipelining. However, these techniques tend to have diminishing returns with respect to the number of pipelines in a processor before stalls become inevitable. In practice no CPU manufacturer makes more than 4 pipelines in a single core.

Multi-core has nothing to do with any of these techniques. This is basically ramming two micro-processors together to implement symmetric multiprocessing on a single chip and sharing only those components which make sense to share (typically L3 cache, and I/O). However a technique that Intel calls "hyperthreading" is a method of trying to virtually implement the semantics of multi-core within the super-scalar framework of a single core. So a single micro-architecture contains the registers of two (or more) virtual cores and fetches instructions from two (or more) different execution streams, but executing from a common super-scalar system. The idea is that because the registers cannot interfere with each other, there will tend to be more parallelism leading to fewer stalls. So rather than simply executing two virtual core execution streams at half the speed, it is better due to the overall reduction in stalls. This would seem to suggest that Intel could increase the number of pipelines. However this technique has been found to be somewhat lacking in practical implementations. As it is integral to super-scalar techniques, though, I have mentioned it anyway.

Pipelining is simultaneous execution of different stages of multiple instructions at the same cycle. It is based on splitting instruction processing into stages and having specialized units for each stage and registers for storing intermediate results.

Superscaling is dispatching multiple instructions (or microinstructions) to multiple executing units existing in CPU. It is based thus on redundant units in CPU.

Of course, this approaches can complement each other.

The idea of the two kinds of exceptions in Java (checked and unchecked) is that checked exceptions should be used for error conditions that can reasonably be expected to happen, and unchecked exceptions should be used for unexpected error conditions.

For example if a file isn't found, you get a FileNotFoundException, and it's reasonable to expect your program to be able to handle such a condition. Unchecked exceptions should be used only for problems that shouldn't happen, and that really mean that there is a bug in the program if such a problem happens. For example, a NullPointerException means that your program is trying to dereference a variable that is null and that's most likely a bug.

The Java compiler forces the programmer to handle checked exceptions. This makes the programming language safer - it means that the programmer is forced to think about error conditions, which should make the program more robust.

The compiler doesn't check unchecked exceptions, because unchecked exceptions aren't supposed to happen anyway and if they do, there's nothing that the program could reasonably do at runtime; the programmer must solve the bug.

There has been some criticism to this feature in Java, some people even call checked exceptions a failed experiment and some people propose to remove checked exceptions from Java.

1. возьмите рубашку с вешалки
2. постирайте рубашку
3. высушите рубашку
4. погладьте рубашку
5. сложите рубашку
6. положите рубашку на вешалку
7. возьмите брюки из вешалка
8. постирать штаны
9. высушить штаны
10. сложить штаны
11. положить штаны обратно на стойку
12. взять пальто с вешалки
13. постирать пальто
14. высушить пальто
15. погладьте пальто
16. положите пальто на вешалку

Дежурный следует этим инструкциям по отношению к футболке, очень осторожно, чтобы никогда не сделать что-либо не в порядке. Как вы понимаете, ежедневная стирка занимает много времени, потому что на полную стирку, сушку и складывание каждого предмета белья уходит много времени, и все это нужно делать по отдельности.

Однако , однажды уходит служитель и новый, умнее, Нанимается дежурный, который замечает, что большая часть оборудования простаивает в любой момент времени в течение дня. Пока сушились брюки, ни гладильная доска, ни стиральная машина не использовались. Поэтому он решил лучше использовать свое время. Таким образом, вместо описанной выше серии шагов он сделает следующее:

1. снимите рубашку с вешалки,
2. постирайте рубашку, снимите брюки с вешалки,
3. высушите рубашку, постирать брюки
4. погладить рубашку, просушить брюки
5. сложить рубашку, (снять пальто с вешалки)
6. положить рубашку обратно на стойку, сложить брюки , (постирать пальто)
7. вернуть брюки на вешалку , (высушить пальто)
8. (погладить пальто)
9. (надеть пальто обратно на стойку)

Это конвейерная обработка. Последовательность несвязанных действий таким образом, чтобы они использовали разные компоненты одновременно. Сохраняя как можно больше различных компонентов активными одновременно, вы максимизируете эффективность и ускоряете время выполнения, в данном случае сокращая 16 «циклов» до 9, то есть ускорение более чем на 40%.

Теперь небольшая химчистка начала зарабатывать больше денег, потому что они могли работать намного быстрее, поэтому владелец купил дополнительную стиральную машину, сушилку, гладильную доску, складывающуюся станцию ​​и даже нанял другого помощника. Теперь все стало еще быстрее, вместо описанного выше у вас есть:

1. снять рубашку со стойки, снять брюки со стойки,
2. постирать рубашку, постирать брюки , (снимите пальто с вешалки)
3. высушите рубашку, высушите штаны , (постирайте пальто)
4. погладьте рубашку, сложите брюки , (высушите пальто)
5. сложите рубашку, положите брюки обратно на стойку , (погладьте пальто)
6. положите рубашку на вешалку, (положите пальто на вешалку)

Это суперскалярный дизайн. Несколько подкомпонентов, способных выполнять одну и ту же задачу одновременно, но с процессором, решающим, как это делать. В этом случае это привело к увеличению скорости почти на 50% (за 18 «циклов» новая архитектура могла выполнить 3 итерации этой «программы», тогда как предыдущая архитектура могла выполнить только 2).

Старые процессоры, такие как 386 или 486 - простые скалярные процессоры, они выполняют одну инструкцию за раз в том порядке, в котором она была получена. Современные потребительские процессоры, начиная с PowerPC / Pentium, являются конвейерными и суперскалярными. ЦП Core2 способен выполнять тот же код, который был скомпилирован для 486-го, при этом используя преимущества параллелизма на уровне инструкций, поскольку он содержит собственную внутреннюю логику, которая анализирует машинный код и определяет, как его переупорядочить и запустить (что может выполняться параллельно , что не может и т. д.) В этом суть суперскалярного дизайна и почему он настолько практичен.

В отличие от этого векторный параллельный процессор выполняет операции с несколькими частями данных одновременно (вектор). Таким образом, вместо простого добавления x и y векторный процессор добавит, скажем, x0, x1, x2 к y0, y1, y2 (в результате получатся z0, z1, z2). Проблема этой конструкции в том, что она тесно связана с определенной степенью параллелизма процессора. Если вы запустите скалярный код на векторном процессоре (при условии, что можете), вы не увидите преимуществ векторного распараллеливания, потому что его нужно использовать явно, аналогично, если вы хотите воспользоваться преимуществами нового векторного процессора с большим количеством параллельных процессоров (например, способный складывать векторы из 12 чисел вместо 3) вам нужно будет перекомпилировать код. Проекты векторных процессоров были популярны в самом старом поколении суперкомпьютеров, потому что их было легко спроектировать, а в науке и технике существуют большие классы проблем с большим количеством естественного параллелизма.

Суперскалярные процессоры также могут иметь способность выполнять умозрительные задачи. исполнение. Вместо того, чтобы оставлять блоки обработки простаивающими и ждать завершения выполнения пути кода перед переходом, процессор может сделать наилучшее предположение и начать выполнение кода после перехода до того, как предыдущий код завершит обработку. Когда выполнение предыдущего кода достигает точки ветвления, процессор может затем сравнить фактическую ветвь с предположением ветвления и либо продолжить, если предположение было правильным (уже намного раньше, чем было бы, просто ожидая), либо он может сделать недействительными результаты спекулятивного исполнения и запустить код для правильной ветви.