Re: new laptop: compiling source for i7 CPUs???
>> The rule of thumb, in general is that a speed increase smaller than
>> about 30% goes unnoticed.
> That 30% sounds about right, but then too I suppose it would also depend
> upon how closely the speed is being examined and how perceptually prominent
> the executable is and other factors.
Of course. That 30% rule is for the case where the user is not actively
looking to see if it's faster.
And of course, in some cases there can be threshold effects. E.g. if
your keys repeat 20 times per second and Emacs takes 0.055s to
redisplay a page after scrolling, a 10% speed increase might be just
enough to go from "Emacs can't keep up" to "scrolling is perfectly
smooth".
> This brings up the next issue: how difficult is it in debian to configure
> the upgrade process so that it is the sources which are automatically
> downloaded and (also automatically) compiled?
I don't think there's any support for that.
> I try to temper my cynicism though in thinking that the designers and
> engineers can and actually intend to produce a better product.
> The corporation as a whole should be fully behind them in this
> endeavor, otherwise competitors will be eating their lunch.
The situation is pretty simple: no one knows how to make truly faster
processors nowadays. Even adding more cores is not that easy because
the main limit is power. There are a lot of physical resources
(transistors) available, but it's hard to make use of them.
So engineers work really hard to find niches where some particular
feature can be useful. It's not just marketing: in general those new
features are really useful, just only in some particular cases. Then of
course, marketing comes along and tries to make you want those extra
features, even if you don't really fit the particular use case.
After all, those extra features are the only really distinguishing
features w.r.t to their competitor (or w.r.t their previous generation
of processors since they want people to buy new processors rather than
keep running old ones).
For example having a video-processing-unit won't help you when running
Emacs, but for those cases where you're watching or encoding a video, it
can work a lot more efficiently than if you had to do it all in your
general purpose CPU. Mind you, maybe that general purpose CPU could
still do it in real time, just like the VPU, so maybe "watching a video"
is not sufficient to see the benefit from the VPU. Maybe you need to be
"watching a video while running on battery" to really see the
difference. But if you do watch a video while running on a battery,
that VPU might extend your battery life by a factor of 2 or more.
> Though my studies never brought me close to taking a role as such an
> engineer, I did learn that if you're going to take the trouble to
> bring out a new design, the improvements should be those which bring
> about the greatest effect, e.g., those instructions which are most
> often used.
We're well into the very diminishing returns part of the curve, so we're
out of ideas as to how to improve "those instructions which are most
often used".
> E.g., getting a 64-bit system is a questionable decision if you're
> going to run nothing but 32-bit software on it.
There are no two processors which are really identical except for one
being 32bit and the other 64bit. So you may very likely choose the
64bit system for other reasons than just because it's 64bit.
E.g. the first 64bit microprocessors where MIPS processors (used in SGI
systems). They were sold several years before SGI came up with a 64bit
operating system and nobody cared that they had a 64bit CPU but were
only using it with 32bit software: these CPUs were faster than the
previous ones and that was what mattered.
> On the other hand, if you're going to run VMs, then a CPU with
> instructions enhanced for that makes sense if you'll be compiling the
> code to take advantage of those instructions, and this also assuming
> that the compiler is capable of creating such executables.
IIUC instructions specialized for VM support aren't generated by the
compiler. They are hand-written in assembly in the VM software (not
sure if it's in the part that runs in the kernel or if it's in the part
that's running in userspace). And the VM will probably check whether
the CPU supports them before using them, regardless of how it was
compiled. So even using Debian's conservative compilation options,
kvm/virtualbox/xen might very well make use of the fanciest feature
you have.
Stefan
Reply to: