Processor - Julio Merino (jmmv.dev)

Processor speed and desktop usage

Back in July 7th, I disassembled my MacBook Pro to see if I could easily replace its hard disk for a faster one. I hadn't bought it yet because I first wanted to check that the whole process was easy. The thing is that, after a couple of problems, I could disassemble it. So I then ran to the local store to buy the new drive. But oh! They didn't have it. I decided to not reassemble the computer as one of the disassembling steps was quite scary and I didn't want to repeat it unless really necessary. Stupid me. It has already been three weeks and they have not yet received any unit; I hate them at this point. And yes, I've been all this time with the laptop partly disassembled, working with external peripherals and without the battery. Which is very annoying because, even though I didn't think I really needed mobility, it is important once you get used to it. Anyway. I have been using the machine as usual all these three weeks, and have kept working on my SoC project intensively. Lately, I noticed that my builds were running slower than as I remembered: for example, I went away for two hours and when I came back a full NetBSD/i386 release build had not finished yet. That was strange, but I blamed the software: things keep growing continuously, and a change in, e.g., GCC, could easily slow down everything. But yesterday, based on this thread, I installed CoreDuoTemp because I wanted to see how the processor's frequency throttling behaved. I panicked. The frequency meter was constantly at 1GHz (and the laptop carries a 2.16GHz processor) no matter what I did. Thinking that it'd be CoreDuoTemp's fault, I rebooted into Windows and installed CPU-Z. Same results. For a moment I was worried that the machine could be faulty or that I had broken it in the disassembly process. Fortunately, I later remembered another post that mentioned that MacBook Pros without a battery installed will run with the processor at the minimum speed; seems to be a firmware bug. Effectively: I reassembled the machine today — with the old, painful, slow, stupid, ugly, etc. disk! —, installed the battery and all is fine again. Why I am mentioning all this, though? Well, the thing is... if it wasn't for the software rebuilds, I wouldn't have noticed any slowdown in typical desktop usage tasks such as browsing the web, reading the email, chatting, editing photos or watching videos. And the processor was running at half of its full power! In other words, it confirms me that extra MHz are worthless for most people. It is "annoying" to see companies throwing away lots of perfectly-capable desktop machines, replacing them with more powerful ones that won't be used to its full capacity. (OK, there are other reasons for the switch aside the machine's speed.) Just some numbers. Building ATF inside a Parallels NetBSD/i386 virtual machine took "real 4m42.004s, user 1m20.466s, sys 3m16.839s" without the battery, and with it: "real 2m9.984s, user 0m22.725s, sys 1m39.053s". Here, the speed is noticeable :-) I will blog again when I have the replacement disk and possibly post some pictures of the whole procedure.

July 27, 2007 · Tags: <a href="/tags/mac">mac</a>, <a href="/tags/processor">processor</a>
Continue reading (about 3 minutes)

Is assembly code faster than C?

I was reading an article the other day and found an assertion that bugged me. It reads: System 6.0.8 is not only a lot more compact since it has far fewer (mostly useless) features and therefore less code to process, but also because it was written in assembly code instead of the higher level language C. The lower the level of the code language, the less processing cycles are required to get something done.It is not the first time I see someone claiming that writing programs in assembly by hand makes them faster, and I'm sure it is not the last time I'll see this. This assertion is, simply put, wrong. Back in the (good?) old days, processors were very simple: they fetched a instruction from main memory, executed it and once finished (and only then), they fetched the next instruction and repeated the process. On the other hand, compilers were very primitive and their optimization engines were, I dare to say, non-existent. In such scenario, a good programmer could really optimize any program by writing it in assembly instead of in a high-level language: he was able to understand very well how the processor internally behaved and what the outcomes of each machine-level instruction were. Furthermore, he could get rid of all the "bloat" introduced by a compiler. Things have changed a lot since then. Nowadays' processors are very complex devices: they have a very deep execution pipeline that, at a given time, can be executing dozens of instructions at once. They have powerful branch prediction units. They reorder instructions at run time and execute them in an out-of-order way (provided they respect the data dependencies among them). There are memory caches everywhere. So... it is, simply put, almost impossible for a programmer's brain to keep track of all these details and produce efficient code. (And even if he could, the efficiency could be so tied to a specific microprocessor version that it'd be useless in all other cases.) Furthermore, compilers now have much better optimization stages than before and are able keep track of all these processor-specific details. For example, they can reorder instructions on their own or insert prefetching operations at key points to avoid cache misses. They can really do a much better job in converting code to assembly than a programmer would in most cases. But hey! Of course it is still possible and useful to manually write optimized routines in assembly language — to make use of SIMD extensions for example — but these routines tend to be as short and as simple as possible. So, summarizing: it no longer makes sense to write big programs (such as a complete operating systems) in assembly language. Doing that means you lose all the portability gains of a not-so-high-level language such as C and that you will probably do a worse optimization job than a compiler would. Plus well-written and optimized C code can be extremely efficient, as this language is just a very thin layer over assembly. Oh, and back to the original quote. It would have made sense to mention the fact that the Mac Plus was written in assembly if it had been compared with another system of its epoch written in C. In that case, the argument would have been valid because the compilers were much worse than they are today and the processors were simpler. Just remember that such assertion is, in general, not true any more.

June 4, 2007 · Tags: <a href="/tags/assembly">assembly</a>, <a href="/tags/c">c</a>, <a href="/tags/processor">processor</a>
Continue reading (about 3 minutes)

Posts: Processor

Processor speed and desktop usage

Is assembly code faster than C?

Featured software

Featured posts