[Info-vax] Microsoft: Alpha architecture responsible for poor Windows file compression

Kerry Main kemain.nospam at gmail.com
Wed Nov 2 13:21:42 EDT 2016


> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Paul Sture via Info-vax
> Sent: 02-Nov-16 12:02 PM
> To: info-vax at rbnsn.com
> Cc: Paul Sture <nospam at sture.ch>
> Subject: Re: [Info-vax] Microsoft: Alpha architecture
responsible
> for poor Windows file compression
> 
> On 2016-11-02, Simon Clubley
> <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
> > According to:
> >
> >
> http://www.theregister.co.uk/2016/11/02/ghost_of_dec_alpha_
> sees_micros
> > oft_dumb_down_windows_file_compression/
> >
> > Microsoft are saying that limits in the Alpha architecture
are
> > responsible for poor Windows file compression in today's
> world. Sample quote:
> >
> >|Chen says one of his "now-retired colleagues worked on real-
> time
> >|compression, and he told me that the Alpha AXP processor was
> very weak
> >|on bit-twiddling instructions. For the algorithm that was
> ultimately
> >|chosen, the smallest unit of encoding in the compressed
> stream was the
> >|nibble; anything smaller would slow things down by too much.
> This
> >|severely hampers your ability to get good compression
ratios."
> 
> Let's back up a little.
> 
> Here's Raymond Chen's article:
> 
> <https://blogs.msdn.microsoft.com/oldnewthing/20161101-
> 00/?p=94615>
> 
> "The requirement that a file compressed on one system be
> readable by any other system allows a hard drive to be moved
> from one computer to another. Without that requirement, a hard
> drive might be usable only on the system that created it, which
> would create a major obstacle for data centers (not to mention
> data recovery)."
> 
> Hmm, I'm not too sure that was ever a practical aim.  It took
> Microsoft until Server 2008 before Windows Backup could restore
> a system disk to dissimilar hardware of the *same* architecture
> and produce a working system.
> 
> Even for data disks, in the mid-1990s there were problems such
> as a given disk getting a slightly different setup via
different disk
> controllers; the number of total blocks differed by something
like
> 4 between SCSI and non-SCSI controllers on the hardware I was
> using at the time.
> 
> So in theory maybe, but in practice taking a disk from one
> architecture to another was fraught with problems.
> 
> > Do any Alpha architecture experts here know if this is the
full
> story ?
> 
> There could well have been other solutions available with later
> iterations of Alpha.  Something as important as this could
maybe
> have warranted a bit of work on the PALcode side of things.
> 
> --

This is likely related to earlier Alpha architectures. Microsoft
was famous (infamous) for doing as little as possible for the
Alpha architecture. 

As an example - Even after MS was told the Alpha Windows Office
products still contained debug code in them (Office on Alpha was
still faster than X86 at the time), they refused to fix this.
Rumor was that Microsoft only did a minimal amount of work to
make Alpha work with Windows because they were forced to after
code was found in Windows that had DTN (among other things) phone
numbers.

As I recall, EV56 introduced byte level instructions which, among
other reasons, were designed to address issues like this.

http://alasir.com/articles/alpha_history/alpha_21164_21164pc.html

21164A (EV56) was introduced at a Microprocessor Forum in October
of 1995. It was a modified release of EV5 after a redesign for a
proprietary 4-layer 0.35µ CMOS6 process. It was manufactured at
the same semiconductor factory in Hudson (Massachusetts, the
USA), and DEC had invested about 450 mln. USD in modernization
prior to. The most important architectural difference was BWX
(Byte-Word Extension) — a set of 6 additional instructions to
load/store data in 8- or 16-bit quanta (LDBU, LDWU, STB, STW,
SEXTB, SEXTW)


Regards,

Kerry Main
Kerry dot main at starkgaming dot com








More information about the Info-vax mailing list