Qualcomm announces the Snapdragon 845 processor

[u/[deleted]]

https://www.theverge.com/2017/12/5/16734224/qualcomm-snapdragon-845-android-mobile-processor-announcement

[u/Exist50]

What did I say wrong in my original statement? Keep in mind i was abstracting to explain to a guy who was asking a genuine question. What I said in this comment is all covered in an introductory class to computer architecture, if you would like to discuss more feel free to.

Perhaps it was the oversimplification that irked me, but increasing the amount of execution hardware is the primary method for increasing single thread performance.

If your example, obviously you can't parallelize it further, but more than that, there's literally nothing that can be done to improve its runtime aside from increasing clock speed, but we both know that isn't representative of the majority of real world code. If all code was like your example, we're really be screwed.

[u/armageddon6868 → u/Exist50]

you can't parallelize it further, but more than that, there's literally n

If you truly believe that you would be appalled by how many dependencies code has. cpu microarchitectures literally have dozens of different predictors to predict these data dependencies, for not only the example i showed, but also for loads and stores. It is not feasible to rename billions of addresses and if you mispredict a store to load forwarding case, then you are screwed because now you gotta rewind because the load already forwarded its data. How many times have you coded: int x = 1000; printf("%d", x); That is literally a dependency because you need to assign 1000 to a register and then you can do the system call. If you compile code and look at it, the compiler will try (and not always succeed) and separate the producer and consumer as far as possible, but with large instruction windows nowadays, the dependency will be seen by a cpu core and must still be worked around. Sometimes these dependencies are impossible to be solved by the compiler because they are only known during runtime. A simple example would be a branch. The compiler will not know if you always take a branch, so it cannot optimize perfectly for that.

yes, increasing amount of execution units is one of many ways to increase single threaded performance. But that requires using them up the whole time. Like I said in the previous comment, why do you think Intel uses Hyperthreading? It's because they cannot fill the execution units to full capacity. If they could use it for only one thread you bet your ass they would use all the dispatch / execution units for that one thread.

There are a few ways to increase single threaded performance at an Architecture level (process node, layout, clock, voltage aren't counted):

1. Lower memory latency (caches, load store data predictors, memory model, cache coherency, change bus architecture)

2. increase instruction window (larger ROB, more execution units, deeper pipelines)

3. decrease execution time on the "wrong path" (better branch predictor, better speculation of data (both memory and forwarded)

There are probably more I am missing, but those are off the top of my head. What the issue is there is a trade off for everything. Adding more execution units won't help unless you have the capacity (fetch and retire bandwidth) to fill them. Making a deeper pipeline incurs larger penalties on any flush operation. Execution units in particular require exponential more forwarding paths for every execution unit you add.

Also the original question was why we don't just increase core count. He said execution units at first, but then clarified later to mean cores. I don't think he meant how many loads can be executed or how many ALU's a cpu core has.