cpu-architecture

I believe that when creating CPUs, branch prediction is a major slow down when the wrong branch is chosen. So why do CPU designers choose a branch instead of simply executing both branches, then cutting one off once you know for sure which one was chosen? I realize that this could only go 2 or 3 branches deep within a short number of instructions or the number of parallel stages would get ridiculously large, so at some point you would still need some branch prediction since you definitely will run across larger branches, but wouldn't a couple stages like this make sense? Seems to me like it

I don't know why L1 Cache and L2 Cache save the same data. For example, let's say we want to access Memory[x] for the first time. Memory[x] is mapped to the L2 Cache first, then the same data piece is mapped to L1 Cache where CPU register can retrieve data from. But we have duplicated data stored on both L1 and L2 cache, isn't it a problem or at least a waste of storage space? I edited your question to ask about why CPUs waste cache space storing the same data in multiple levels of cache, because I think that's what you're asking. Not all caches are like that. The Cache Inclusion Policy for an

I just updated to the newly released Xcode 5. I have an iOS app under development that uses the Google Maps iOS SDK. Back when I was developing in Xcode 4, I changed my Architectures setting in my project settings, as per step 7 of Google's instructions for adding the SDK to the project : 7. Choose your project, rather than a specific target, and open the Build Settings tab. Replace the default value of Architectures with armv7. In the Other Linker Flags section, add -ObjC. If these settings are not visible, change the filter in the Build Settings bar from Basic to All. Everything was fine in

Last Branch Record refers to a collection of register pairs (MSRs) that store the source and destination addresses related to recently executed branches. They are supported across Intel Core 2, Intel Xeon and Intel Atom processor families. http://css.csail.mit.edu/6.858/2012/readings/ia32/ia32-3b.pdf document has more information in case you are interested. Is LBR-like feature available only in Intel microprocessors OR something similar exists in ARM etc. ? To sum up, as Carl mentioned, ARM also has program tracing functionality on some processors. This site has interesting details about this

I was able to put together bits here and there about the Sandy Bridge-E architecture but I am not totally sure about all the parameters e.g. the size of the L2 cache. Can anyone please confirm they are all correct? My main source was the 64-ia-32-architectures-optimization-manual.pdf On sandy bridge, each core has 256KB of L2 ( see the datasheet, section 1.1 ). for 6 cores, that's 1.5MB, but since each core only accesses its own, it's better to always look at it as 256KB per core. Moreover, the peak gflops looks completely wrong. AVX is 16 flops/cycle (as single floats). with 6 cores, that's

According to wiki : Non-uniform memory access (NUMA) is a computer memory design used in multiprocessing, where the memory access time depends on the memory location relative to a processor. But it is not clear whether it is about any memory including caches or about main memory only. For example Xeon Phi processor have next architecture: Memory access to main memory (GDDR) is same for all cores. Meanwhile memory access to L2 cache is different for different cores, since first native L2 cache is checked, then L2 cache of other cores is checked via ring. Is it NUMA or UMA architecture?

If new CPUs had a cache buffer which was only committed to the actual CPU cache if the instructions are ever committed would attacks similar to Meltdown still be possible? The proposal is to make speculative execution be able to load from memory, but not write to the CPU caches until they are actually committed. TL:DR: yes I think it would solve Spectre (and Meltdown) in their current form (using a flush+read cache-timing side channel to copy the secret data from a physical register), but probably be too expensive (in power cost, and maybe also performance) to be a likely implementation. But