Tag Info

Hot answers tagged

45

If the code says A = A + 1 compiled code does this add A, 1 interpreted code does this (or some variation) look up the location of A in the symbol table find the value of A see that 1 is a constant get its value add the value of A and the value of 1 look up the location of A in the symbol table store the new value of A get the idea?


37

They're not quite the same. The registers are the places where the values that the CPU is actually working on are located. The CPU design is such that it is only able to actually modify or otherwise act on a value when it is in a register. So registers can work logic, whereas memory (including cache) can only hold values the CPU reads from and writes to. ...


20

CPU (its memory controller specifically) can take advantage of the fact that the memory is not mutated Advantage is, this fact saves compiler from using membar instructions when data is accessed. A memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction which causes a central processing unit (CPU) ...


16

However, with all of these new systems, it seems as if GPUs are better than CPUs in every way. This is a fundamental mis-understanding. Present GPU cores are still limited compared to current top-line CPUs. I think NVIDIA's Fermi architecture is the most powerful GPU currently available. It has only 32-bit registers for integer arithmetic, and less ...


16

As mentioned by Twisol, you are probably looking for "word-size", although what you should really be saying is: "The registers (integer/address) of my CPU are 64-bits wide"* You are definitely not looking for Instruction Set, as this is simply the actual set of instructions that a CPU understands. Your 64-bit CPU will have a 64-bit instruction set, but ...


15

No, instruction sets aren't "standardized" in a way that you could produce assembly that's fit for – or is simply mappable to – ARM, x86, PPC, MIPS, Itanium, Sparc, ... (and their variants). Native code compilers are pretty complex beasts. Not all the work they do is processor-specific. All the lexing/parsing is language-dependent but not ...


14

There are actually several reasons. First and probably foremost, the data that's stored in the instruction cache is generally somewhat different than what's stored in the data cache -- along with the instructions themselves, there are annotations for things like where the next instruction starts, to help out the decoders. Some processors (E.g., Netburst, ...


14

The best answer I can think of is something I've seen repeated over and over: Don't prematurely optimize. The longer version of that is: The compiler (presumably) knows much more about the target architecture than you do. You should write your code to be correct and maintainable, if the underlying hardware changes, you don't want to have your code too ...


14

Intel had 5 pipeline stages in its original Pentium architecture. The number of stages peaked at 31 in the Prescott family, but decreased after that. Today, in the Core series II processors (i3, i5, and i7), there are 14 stages in the processor pipeline. Microarchitecture Pipeline stages P5 (Pentium) 5 P6 (Pentium 3) 10 P6 (Pentium ...


13

we wanted it to be compiled so it’s not burning CPU doing the wrong stuff. Sounds like they are referring to compiled vs interpreted. Most likely down to the whole story of Twitter moving background processing tasks to Scala (compiled) after initially developing in Ruby On Rails (interpreted). An explanation of compiled vs interpreted code here. ...


12

The lines of code have nothing to do with how the CPU executes it. I'd recommend reading up on assembler, because that will teach you a lot about how the hardware actually does things. You can also get assembler output from many compilers. That code might compile into something like (in a made up assembly language): load R1, [x] ; meaning load the data ...


12

I believe it comes from the very early days of computing, when memory was very limited, and it was not wise to pre-allocate a large chunk of memory for exclusive use by the stack. So, by allocating heap memory from address zero upwards, and stack memory from the end of the memory downwards, you could have both the heap and the stack share the same area of ...


11

If you're talking about the difference between: if (isTodayAHoliday(now) > 0) { ... } And: int holiday = isTodayAHoliday(now); if (holiday > 0) { ... } Then the answer is simple: there is absolutely no difference in the machine code. Remember that the CPU knows nothing about functions or expressions. The branch instruction doesn't take a ...


11

I wouldn't say it was the first. Core War at least has been around since 1984. Core War (or Core Wars) is a programming game in which two or more battle programs (called "warriors") compete for the control of the "Memory Array Redcode Simulator" virtual computer ("MARS"). These battle programs are written in an abstract assembly language called Redcode. At ...


11

Yes, there is a Data Acknowledge signal. It asserts that the data has been placed onto the memory bus, and is available to the processor for reading. Briefly, the memory read cycle works like this: The processor initiates a read bus cycle by floating the address of the memory location on the address lines. Once the address lines are stable, the processor ...


10

Yes, your P4 desktop will be hugely faster than a cell phone. I used to work on a cell phone OS. This was a few years ago, and we were using XScale and OMAP ARM CPUs, and we also had a desktop simulator that ran the same code compiled for x86. I never measured it, but 27x is certainly plausible. There are a ton of factors involved other than raw CPU clock ...


9

Real/Actual errors in a CPU's design aside, I think you are looking for this SO Question: Cosmic Rays. What is the probability they will affect a program. I can't get quotes from it because SO is blocked again at work here (sigh). Ignoring the above, I seem to recall there was some FPU calculation bugs in early Pentiums, so they certainly are not ...


8

GPUs aren't generalist processors the way CPUs are. They specialize in doing one very specific thing--applying the same code to a large amount of data--and they do it very, very well, much better than a CPU does. But the majority of most applications is not about applying the same code to a large amount of data; it's about an event loop: waiting for input, ...


8

"Wrong stuff" here means the overhead it takes for the interpreter to parse and process the code. It's connected with the notion of interpreted vs compiled languages. There are several models of code translation in use, which roughly fall into one of following categories: Native compilation - source code is directly compiled into machine code. Best ...


7

This topic triggers an old debate of CPU vs GPU, and there are tons of documents and papers out there explaining the differences between these processors. But just to summarize a few things, remember that each processor was made for a specific task. GPUs dedicates more transistors to data processing, and from the memory usage point of view, CPU is optimized ...


6

The simple answer is that a GPU works best when you need to do a fairly small, fairly simple computation on each of a very large number of items. To accomplish much this way, the computation for each item must be independent of the computations for the other items. If there's (normally) some dependency between one item and another, you generally need to ...


6

Well, there are instructions that don't access the data cache, but it's impossible to access the data cache without using an instruction, so by definition the instruction cache is used more often. If you're talking about which one has fewer cache misses, that's going to be highly program specific. A tight loop that accesses a gigabyte of memory will have ...


5

There's a lot more to performance than raw CPU number-crunching power, even on CPU-bound algorithms. The efficiency of the compiler (and the JVM implementation if you're working with Java, which you are likely to be doing on an Android phone,) the amount of memory available and the size of the bus, the size of the processor's caches, etc all factor into it. ...


5

Theoretically possible, but I doubt it: Cost of developing the CPU would far outweigh the benefits The JITer already does a "good enough" job IL is subject to change with new releases of .Net, so benefits would be short-lived Sorry - nice idea, but unlikely to happen.


5

Many times, operations like floating point and memory management are encoded in a way that they can be "trapped". This means that the system can be configured to either use hardware or automatically branch to a software implementation. In the case of software, the implementation can be anything, although most manufacturers supply libraries that follow ...


5

The popularity come first from exposure: the Minecraft community isn't small and there is a non-insignificant subset of them that likes to mess around with specifics and technicalities and would see imlpementing the DCPU-16 emulator as a personal challenge. Second, it's a very compact specification geared towards easy implementation (*). I'd be able to ...


5

So, can multiple CPU's / cores access the same RAM simutaneously, or is what I'm saying correct? There are many different machine architectures out there, each with its own set of features. One category of multiprocessing machines is called MISD, for Multiple Instruction Single Data, and such machines are designed to provide the same data to several ...


5

I don't know how much the designers of the ARM architecture took inspiration from the PDP-11. They probably knew the PDP-11 architecture well as it was one of the major CPUs of the 1970s. However, it's more the x86 which is different from the other two. ARM is a RISC architecture: its instructions tend to follow a few model and to do just one thing. Compare ...


4

The only real difference you'd notice when using a HLL is going to be code size, and discovering that some features/libraries aren't available for x64 yet. Oh, and x64 code tends to be less performant, at least under .NET. The app I'm working on runs about 20% faster when I compile for x86. I don't know if it's because I use more bus bandwidth moving ...



Only top voted, non community-wiki answers of a minimum length are eligible