Why are still not at 64 bits

Jon 'maddog' Hall maddog at li.org
Thu Feb 15 10:44:07 EST 2007


> 
> We still have IPv4 over IPv5 because:
> 
>   - IPv4 provides plenty of space once everyone realizes that all 5000
>     of their internal systems do not need to be reachable by an actual,
>     internet-routed IP address. (i.e. NAT has "saved the day")
> 
>   - IPv6 has taken forever and a day to get properly defined
> 
>   - IPv4 is intuitive and "makes sense" vs. IPv6 which is neither
> 
>   - It's a lot of effort to switch to a new addressing scheme.

I will replace all of this with two reasons:

	o most people do not understand the value of IPv6, particularly
	  in VOIP and P2P areas.
	o most people (and some VERY large companies) have a nested
	  investment in IPv4 technology that did not justify jettisoning
	  that technology until it wore out
	o Some companies profited from requiring a
          Peer-to-Server-to-Peer connection in order to traverse the
          NATwork
> 
> So, what's keeping us from moving to 64 bits?
> 
>   - There is no NAT equivalent, nor is any really necessary, is there?
>     Won't 32-bit apps continue to work on a 64-bit platform?

      Yes, if written "correctly".  I have seen well-written code, even
      binaries, work without change
> 
>   - We don't have to wait for the technology to stabilize, it's been
>     around for 20+ years (I'm assuming it was being researched for
>     quite some time before DEC released the Alpha as a commercial
>     product)

      And many people are using 64-bit native today and benefiting from
      it
> 
>   - From an end-user perspective, do they need to care or know?  I
>     guess if you define end-user to be application developer in this
>     case, then the answer is yes.  Not being such a person, how much
>     more difficult is it to develop a 64-bit app vs a 32? (I'm *not*
>     talking about porting it, mind you).

      They would care if they knew what it would do for them.
> 
>   - Is it a lot of effort to switch to a new addressing scheme in this
>     case?  What's to be done?  All major OSes have been ported and run
>     on 64-bit platforms.

      Ahhhh, here is the catch.  It depends on whether you consider
      Microsoft's products to be "major OS".

      Only in Vista have they actually used a 64-bit ADDRESS SPACE.
      Their claims to "64-bit" before have been limited to data types,
      and (perhaps) data flow through cache and other pipelines.

      Without Microsoft's support of ADDRESS SPACE, a lot of software
      vendors would not take the time or effort to re-design their
      applications to utilize that space.
> 
> I guess my argument or rather confusion is this.  64-bits is here, has
> been for a while, and is stable.  So why don't we see more of it?
> It can't be just a matter of "32 bits is good enough".
> 

No, it is "what percentage of the market are you going to sell to?"
What market does Nvidea sell to?  What market does any of your
"CompuHUT" software market sell to?

But on the other hand, what systems are the scientists at the National
Labs using that need to process a terabyte of data a day?  It is not
Windows.  And they aren't using 32-bit processors.

This is why all the large database vendors went to 64-bit servers
long ago.  Of course they wrote their software "right", so they can say:

	o "build crappy 32-bit version"

OR

	o "build much better 64-bit version"

Ask THEM which type of system you should buy.  You will not hear
anything with "32-bit" in the name.

Many, MANY years ago we did a little trial at Digital with the help of
our friends at Oracle.  Same 64-bit Alpha machine, same amount of main
memory, same amount of disk, etc.  We had them run Oracle in 32-bit mode
and in 64-bit mode doing a 6-way join.  The 64-bit version was 200 TIMES
faster, due to algorithm changes which allowed them to have all the data
in memory, fewer levels of indices, etc. etc.

Why didn't the world just jump on 64-bits after that?  Oracle saw no
need to publicize this, and Digital could not market.

Thus we have it.

md



More information about the gnhlug-discuss mailing list