Jump to content
The Inquirer-Home

The last of the 64bit letters and more

Letters Dvorak gets it in the ear
Wednesday, 9 April 2003, 23:24
I WAS DELIGHTED to see Harta Glass's article titled "Unholy Row Breaks Out In US Over CDMA, GSM Phones," describing my fellow Qualcommer Jim Mullens and his campaign to convert me and others that post to various wireless message boards that we should support "the cause."

I just recently persuaded Jim to define this "cause." He did so as follows:

"Re: "the cause"- and your gathering that it's an effort "to educate the non-believers". It is more of an effort to educate the journalists by pointing out their inaccuracies and omissions regarding CDMA and Qualcomm with the hope that eventually we as investors will get fair and balanced reporting of the issues impacting our investments in the wireless industry."

I think I'll pass on that one.

Perhaps you could explain something to me. Harta's article refers to "American journalists like ... Theresa Orlowski." I assume, perhaps incorrectly, that Theresa is Andrew (in San Francisco, not London). If that is the case, are you able to share how Andrew came to be Theresa?

As Andrew would say (once said) when referring to the nutball fringe of Qualcomm's barmy army of loyal headbangers:

"Now, not all Qualcomm defenders belong to right-wing militia groups, but a weirdly disproportionate number would seem to qualify".

Thanks for your time. Harta's article was great fun.

Best Regards,

Eric

alt='scissors'

Dear Ms. Glass,

You had been writen:
>....
>But what's more interesting - according to Tarq - is that >Win64 support for AMD's Opteron is likely to arrive with >SP1 of Windows Server 2003 by year end. By that time, as >he kindly pointed out, Athlon64 will be a reality that even >hunky chemist Paul R. Engel will not be able to ignore.

but i have another information

from URL: http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q816915
jwhich seems to be clear:
that
64 bit Windows will be in 3. versions:
Microsoft Windows Server 2003, 64-Bit Enterprise Edition
Microsoft Windows Server 2003, 64-Bit Datacenter Edition
Microsoft Windows XP 64-Bit Edition

and it is clear, that 64 bit Win will be also for x86-64 platform as soon as posible.
(use of Itanium in desktop based on Win XP is unlogic)
And when Microsoft will be able to propduce x86-64 kernel for any NT5.x based Windows, than all NT5.x based Windows may run on this kernel.

Option (Optional attribute)
Used to differentiate hotfix packages that address the same issue but are designed for different processor platforms. These options include:
x86 (for 32-bit processors)
AMD64 (for x86-64bit AMD processors)
IA64 (for 64-bit Intel Processors|
It all seems like Win for x86-64 will be released sooner than Tarq reports..

Yours faithfully
Peter Fodrek

alt='scissors'

Dear Eva,

Well - to make it short: I just love the style you write your articles. I *errr* have nothing more *uhmmm* important to write in this *eeerrrrchhh* mail here, just wanted to provide some positive feedback :)))

Lacking the funds for an Optimisteron (rise share... rise! *slap*) i can barely restrain myself not to moan in pleasure dreaming about my Athesteron-64 clusters in the near future *g*

Keep on your good work.

Regards,
Lars

alt='scissors'

So "Eva", I believe the charade can go on no longer. I know your true identity is Fudo! Whenever he partakes in a trip to Las Vegas (don't know why I didn't see that a long time ago) to scratch that gambling itch, he gets a little liquored up and starts a typin', right?! This must then have the odd effect of correcting some of those nasty grammar 'opportunities' in the articles (sorry Fudo!) - right?! That would explain some of the cryptic rambling Ms. Vegas (oop - Glass) adds to the art's to spice them up. Sheesh, indeed.....

So.... what do I win?

Email address supplied

alt='scissors'

I am probably beating a dead horse with a letter on x86-64 vs. 32-bits, yet I still felt compelled to write one. The thread on realworldtech.com on Opteron revealed a fascinating thing about differences in thinking of hardware and software people. Pretty much the same pattern is observable over and over again in countless discussions across the Web.

Fundamentally, what many hardware types seem not to understand (Intel, Demone, Kent, the guy from overclockers, etc.)

how incredibly expensive it is to produce software of reasonable quality and make sure that it works at least OK. That is why it takes years for programmers to start using non-essential new instructions on large scale, and why the ability to run whatever programs one already has precompiled and tested is so indispensable. Considering that only about 5% of software is written for shrink wrap sales, and the remaining 95% for internal use, there is a huge group of people who fully follow "if is not broken - don't fix it" principle.

The hardware designers mostly deal with the answer preserving transformations, which are a lot easier to get right since the right answer is almost always known. With software the right answer often needs to be first discovered and this often happens after a lengthy debugging. The complexities multiply. Even when software seems to be working, full verification is almost never achievable.

With many instruction set as well as 32-64 bit transitions, IBM, Sun, HP, SGI, and occasionally even Intel made sure that old code could run on new CPUs well. Those guys understood what software users wanted. PPro which ran 16-bit code poorly eventually had to be fixed in what became PII. Apple's instruction set transitions were probably saved by the religious customer base and the creative genius of Steve Jobs who's OSes are so much nicer than alternative offerings in the same time frame.

x86-64 offers a fully painless migration, where those who need more than 2Gb RAM get it in an easy to program way. And RAM barriers are the most costly to fight because they need code to be rewritten. The performance issues could at least be waited out and thus are a lot more tolerable. That is why all the programmers and users out there are so excited about x86-64. IA64, on the other hand, tries to fight the world. Good luck on that one, even Intel's billions won't be able to buy out all those folks who got better things to do than to work on moving whatever they have to IA64 for small performance benefits. Intel's x86-32 line is a dead end, where is the future in slightly faster CPUs with the same stupid 2Gb per program limits? A lot of x86 servers already have 2Gb and choke on demanding applications.

Email address supplied

alt='scissors'

I am probably a little too retarted to know this, but I thought that the limit was 2GB and not 4GB; Something like -2,147,483,648 2,147,483,648 was the limit. If you wanted to go up to 4GB you would have to make the application use more one thread form the Memory.

Email address supplied

alt='scissors'

It is clear that at some time in the future, the average desktop system will need to be a 64-bit system. However, I believe that is a few years off yet. Here is why:

32-bit machines are not limited to 4GB. 32-bit OSes support more than 4GB. What they don't do is allow a single process to address more than 4GB (or less). This means that 32-bit machines with 8, 16 or perhaps 32GB are quite viable (I would hate to see the spreadsheet that required more than 4GB!)

There seems to be a general assumption that 64-bit machines will be faster than 32-bit machines. I believe that this will only be true for a very limited number of applications: typically those that are dominated by high-precision floating point calculations. At work, when comparing jobs run on SPARC (64-bit) vs. jobs run on Xeon processors, we have seen run times that are closely related to the clock speeds -- no advantage from 64-bit hardware/OS.

Where I work, we have some 64-bit (Solaris on SPARC) boxes. Even on the 64-bit machines, we run 32-bit applications, because the same application runs faster if compiled for 32-bit operation than if compiled for 64-bit operation. Yes, that's right, many 32-bit applications run faster on 64-bit hardware/OS than their 64-bit counterpart. The only reason for us to move to 64-bit application is because a *single process* requires more than 4GB of memory.

If we assume that the average new desktop machine today has 512MB installed and that this number doubles every 12-18 months and that 32-bit machines remain viable up to between 16-32GB of memory, then, based on memory requirements alone, we can assume that 32-bit desktops will remain viable for another 5-8 years.

Of course other factors (floating point operations, "gee-whiz", etc) may accelerate the transition to 64 bit. However, the primary factor may be where AMD and Intel choose to devote their R&D dollars and hence which processors (32 or 64-bit) deliver the highest clock rates.

Email address supplied

alt='scissors'

Just a comment on the letter from 'Jim' about how the OS could support the multi-segmented memory model of the x86. It already does - at least some (I think all) versions of Windows 2000 support a 35-bit virtual address space. Individual applications (i.e. processes) cannot access more than 2GB (4GB including kernel space) each without special programming). I think there is even an extension to this available for the really big iron DataCenter versions of Windows.

I think one of the most exciting things about the IA64 that I haven't heard mentioned much is that it is supposed to be fully virtualizable in hardware. I don't know if it is true, but it'd be great if it was - effeciently running two or more OS's would be very useful and long overdue.

Regards,
Jim

alt='scissors'

In your most recent letters roundup, Jim writes:

It seems to me that, if the O/S were to support the multi-segmented memory model, then maybe we could just limit one process's memory space to 4GB (and maintain the "flat" memory model on a per-process basis.

This is essentially how Windows and Linux support the 36-bit PAE (Physical Address Extension) mode of newer x86 processors, which allows >4GB memory in a system.

There are two problems: one, it doesn't address the case of an individual process needing more address space (and big RDBMSes do), and two, the performance of a machine like this sucks like a very big sucky thing indeed. PAE is not a serious alternative to 64-bit computing; see Alan Cox's comments on the subject for details.

Charles

alt='scissors'

Jim's letter is not really relevant.

IIRC, Windows 2000 Enterprise Edition supports up to 8Gb of physical RAM, and Datacentre Edition up to 64Gb of physical RAM, which is the maximum supported by the Pentium Pro (P6) and NetBurst (Pentium 4, latest Xeons) families of processors.

However, processes can't access this amount of memory directly; each process only has access to 4Gb - as you say, from each selector. In fact, under Windows 2000 each process can only access up to 2Gb of user-mode memory (the other 2Gb reserved for the kernel) unless the system is booted with the /3GB switch and the executables are all linked with the /LARGEADDRESSAWARE switch to the linker. This last switch sets a flag in the executable header telling Windows that it's OK to give addresses >= 2Gb to the program. [1]

The memory is demand-paged, with physical memory mapped to virtual addresses as and when required. The OS can map any physical memory, even that above 4Gb (physical), to any virtual address in the process.

It probably wouldn't be a good idea to change the segment behaviour now (i.e. in order to allow different selectors to have different virtual address maps); programs, the OS and existing compilers all expect the code, data and stack segments to point to the same place - this simplifies the generated code, since certain registers default to using particular segments (i.e. ESP, the stack pointer, defaults to referencing through the SS register, EIP through CS and the data registers through DS). Using a different selector requires longer instructions. We'd be back to choosing memory models when compiling, something that I've thankfully rarely had to think about since most of my work has been with Win32.

The situation is complicated somewhat by Address Windowing Extensions support, where the programmer can reserve a set of virtual addresses as a 'window' to view physical memory through, then allocate pages of physical memory to use. I believe SQL Server 2000 Enterprise Edition is capable of doing this, if there's enough memory to make it worthwhile.

It's very complicated and not especially fast. I think that on x86, all selectors essentially need their own page table, which wastes memory. It also means that this memory can't be swapped to disk and reused by a different process.

Anyway, the point is that the OS already does what Jim suggests, except the use of multiple selectors.

64 bit solves the above problems by giving each process a full 2^64 bytes address space, which again the OS reserves a lot for itself. At present, Windows 64-bit editions allow up to 8 terabytes of the virtual address space for user mode.

More information in 'Inside Windows 2000, 3rd Edition' by David Solomon and Mark Russinovich, by MS Press.

[1] The 32-bit edition's /3GB switch compromises the performance of the system in some areas (e.g. memory available to drivers, amount of system cache available) so the scenario needs to be tested thoroughly to ensure that setting this switch actually improves rather than deteriorates performance.

Mike

alt='scissors'

I don't get it...
Many readers complain about the need for 64 bit....
This isn't a point, when software surfaces the market for the x86-64 CPU's you need the CPU, period. Until then, you can just stick with your "old" 32 bit CPU. There is really no point to stick with a 32bit CPU after September as the 64bit will be just as fast and more future proof then the "old" 32 bit one.

Staying at 32 bit is just as stupid as still trying to run Win3.1 on a 80286, as it can run just the same software IF it was still produced. The 80286 also had Windows, Wordprocessors and games, so why switch to 32 bit? More memory? That can be solved....we heck no it can't...as you are very limited on the memory limits per process.

That is where the problem is, 4GB isn't enough nor will the new limits set by the 64 bit extensions. Gamers run allready in the limits of 32 bit, not to mention the CAD-CAM world. It's the same as with car's, they get better and more advanced over time, live with it! If you don't want it, drive a T-Ford :-)

Bas.

alt='scissors'

You can go on and on about whether or not consumers really want/need more than 4GB of RAM but that's missing half the point:

1) x86-64 programs have access to 8 more general purpose integer registers. This will make programs recompiled for x86-64 ~10% faster even if they don't use a ton of memory or do fancy 64-bit operations.

2) The 64-bit part of x86-64 chips takes up less than 5% of the die. If it only costs a few bucks extra, why the long arguments about whether or not it's necessary?

Tom

alt='scissors'

The Opteron's future looks good. Not so for Athlon64 with its single channel of DDR. Gamers and power users will have Opterons under their desks just to keep similar bandwith to modern pentacle4 chips. Laptops won't have 8GB for two more years it appears. Isn't a value desktop w/Athlon64 and 8GB RAM an oxymoron?

If the Athlon64 is priced at $100 or so it may survive but will be fighting its Athlon32 siblings for some time. At that price and with the right blade chassis it could make inroads to budget distributed computing farms and the nearly-defunct ISP colo. The best thing I can say about the Athlon64 is it will push a unified architecture and get software developers running on a budget.

Regarding supercomputers, we need simple & cheap hypertransport to infiniband interfaces. Start with n-way nodes, Opteron for the big I/O, just add ib switches and low-level code for a single system image and you've got nested (tiered) NUMA on linked n-way nodes. So how big could these systems get? That will depend on the operating system and the "mental" capacity of process schedulers.

Who makes 100+ cpu tin these days? They're not threatened if the resident engineers & management are adept enough to adopt commodity parts whenever possible.

Cheers,
Will

alt='scissors'

Subject: http://www.theinquirer.net/?article=8804


"The tool will become available this quarter for Windows XP Pro and Windows 200 systems and costs $1,198 for a single user licence. "

WTF???

So let me get this straight....

1) Intel create a new CPU Core which can utilise more than one system thread, effectively offering dual processors to applications which take advantage of Hyperthreading....
2) This forces companies to recode their work to include this new technology -- at an extremely non-trivial cost.
3) It's to Intel's ADVANTAGE to have programmes using hyperthreading -- sells more CPUs
4) Intell want to charge $1200 for a single user licence to debug programs developed for Hyperthreading

OMFG! Someone shoot the management of Intel! Those dirtbagging, money grubbing Snot-eaters! AAARGH!

Chris

alt='scissors'

http://www.theinquirer.net/?article=8811 : does this mean that a Microsoft-based department such as ours now has a built-in "poison pill" - if we get outsourced of our jobs / contracts / pensions (TUPE doesn't cover pensions, I think), all of the software has to be paid for over again?

Sounds like job security!

Egan replies

I see Microsoft's onerous license terms as good reason to consider Open Source rather than an influence on outsourcing.

I hesitate to speculate about the impact of the Vole's licensing terms on job security. However, one might reflect that software and support costs, even high Microsoft ones, are dwarfed by salary and benefits.

alt='scissors'

Subject: how the vole sleeps at night..

honestly, given their history, a trifle like a license written specifically to screw you couldn't possibly disturb their sleep. To effect their sleeping patterns they'd have actually have to write into their contract ownership of your immortal soul. Probably the only reason they don't is because they haven't figured out a reasonable way to collect. ;)

Email address supplied

alt='scissors'

Subject: What's that about 'Valve sound is back' ?

Valve ("tube", this side of the pond) sound never left, for some of us die-hard maroons. I still drive my Magnepan Tympani I-D's with a Berning EA2100 (hybrid, with a valve output stage) power amp and a Berning TF-10 (all valve) pre-amp. The Tympanis go back to about 1980, while the pre-amp and amp were "in" from about 1982 to 1987. [The TF-10 gave way to the TF-12, and I'm a bit hazy on the model number of the later Berning power amp - possibly it was the EA2102.]

[Back in my closet I have a couple of old McIntosh mono valve power amps [an MC-60 and an MC-75] and a truly unique amp that I bought used (as with all my other amps and pre-amps) - an (earlier model) Berning 2-150 power amp, which was built and sold as a hybrid, and then was modified by Berning on special order to convert the entire audio path to valves. (When I had a minor repair done on that amp, David Berning told me that the project had been a waste of his time and the customer's money; he said the sound was absolutely indistinguishable from the standard 2-150.)]

Berning said that the only real benefits of valves were in the output stage of a power amp and the various first input stages of a pre-amp, and that his pre-amp designs were all-valve only because of the 'all-valve' prejudice of the US high-end market.

John
P-D, I
Tubes Forever

alt='scissors'

Subject: FLAME!!!

Thought I should repsond to some of mr/miss angry's mad in the head comments.

KT400 was released becasue just like every other recent VIA chipset bar the KT333 (which was a decent piece of engineering & didnt require a revision) the product was rushed to the market to either be 1st or to at least provide a competeing product. Why else was it's performance in many cases worse than the KT333 chipset, it was released with plenty of hype surrounding it & it's 333fsb support but if you used a 266fsb processor you were better to stick with a KT333 board. KT400A is the same firefighting measure that Via always wheel out to shore up underperforming chipsets.

Mvp3 was no faster than ALI Aladdin IV & V SS7 chipsets & ALI support the SS7 platform long after Via had abandoned development of their chipsets, providing ultra 100 southbridges that were compatible with their SS7 northbridges.

KX133 running PC133 wasnt appreciably faster than the Irongate 750 chipset using PC100 ram.

KT133 & KT266 are noticeable by their abscence from the above hall of fame as neither were particullarly great espceically the KT266 which was noticeably slower than AMD's 760 chipset.

Apollo/Pro//133 chipset are also notable by their abscence as the flamer obviously knows these chipset were never able to match Intel's BX & i815 chipset for Slot1/S370 performance. Only the Pro266 chipset could exceed the BX/i815 performance nut when it was released DDR memory was very expensive and the performance difference was small, thus it bombed.

Via has been used to having the run of the Athlon playing field & now that nVidia & SiS have finally gotten serious about producing fast chipsets (it was the amazing sucess of the sporty SiS 735 that prompted the KT266A as far as I remember) VIA no longer have the game to themselves, the flamer should be thankfull it isnt just competition between Intel & AMD that's good you know.

Cheers
Mark

alt='scissors'

I've read Doug's last two articles which, to be frank, are no better than the first one (which was a bag of arse). This really isn't the sort of stuff one expects out of the Inq - it's making The Reg look techy.

I could write better articles than that, and I'd be willing to do it for nowt.

Email address supplied

alt='scissors'

I read in horor the Aloha Bob snafoo I wish i had told you about that nightmare whomever used it better get out the Spybot Search and Destroy and get rid of the spyware they put on your pc that whomever wrote the thread didn't realize was there .Tell the person next time use Norton Ghost 2003 make a boot floppy from it and Ghost over the files easy as pie you do have to have a little bit of Pc smarts to do it but nothing that would require Technician Title.Aloha is terrible i wouldn't recommend it to Sadaam or Bin Laden .

Freddy

alt='scissors'

Itanic for Apple? Pure lunacy. It will never happen; here is why:

The Itanium is a very expensive processor, by design. Forget about the mega-millions spend on development, which need to be recouped. Forget about the power requirements that are easily double an Athlon, and the subsequent heat production. This is a "server" chip, and Intel intends to get very fat margins off each one sold. $2000 processor in a $1000 computer? Not sure how that's supposed to work.

I'm not sure why this guy (Dvorak) makes such an obviously illogical association. Why would a low-volume, high-margin, hot, power-hungry server processor be inevitable for a computer firm known primarily for their desktop boxes and notebooks? But then again Dvorak has a long history of really bone-headed predictions and beliefs, so I guess in that light it makes sense.

Email address supplied

alt='scissors'

I really need to find a copy of that 1987 PC Magazine article (the cover article, IIRC), about how much better MS-DOS 3.0 was than Unix. Because if my memory serves me, that same issue had Dvorak article about how Apple was going to *have* to port the MacOS to the x86s.

It's nice to know that in a world of constant change, some things remain the same.

1) Jobs is playing a different game than Gates. Gates would be going beserk in Jobs' situation- but Gates is playing for money and marketshare. So long as Jobs has enough buyers to finance building what he consdiers to be really cool computers, he's happy. The other 95% of the market share isn't worth it to Jobs to create a less than cool computer. Gates may sell his mother to white slavers to get that last 5%, but Jobs could care less.

2) If Apple ports MacOS to the x86, Apple joins DR-DOS, OS/2, Next, and BeOS in the graveyard of dead Microsoft competitors. The PowerPC prevents Apple from getting much above 15% market share, but also protects that last 5%. Primarily because Windows doesn't run on the PPC.

3) Don't beleive the hype. The Itanium, at least in current incarnations, isn't that good of a performer. Long rant on ILP and limitations of compiler design and current languages available upon request. It certainly isn't fast enough to support a switch over. People forget that when the PPCs were introduced by Apple, they were enough faster to *emulate* at least a mid-speed 68K. And native code was signifigantly faster than anything the 68K could supply. The Itanium is at best competitive *running native code*- even with hardware acceleration it's emulation speed of the x86 is abysmal. If the Itanium was capable of emulating a 800MHz-1GHz G4, I'd say maybe. People don't want to have to buy all-new software with their all-new hardware (too much money all at once)- and they want their new hardware to be at least decent compared to the old hardware. Which has been the problem with the Itanic in the x86 world as well.

4) Intel execs may very well be willing to sell their mothers to the white slavers to get the Itanic up to even a 5% market share- last year they sold, what? 4,500 machines? The problem is that they'd have to signfigantly lower their CPU costs to do so- it's kinda hard to pay $3K per CPU, even at Mac prices. Which means even were Apple to do this, the cost lowering that would have to go on would make it not worth while for Intel (not that the Itanic is worth while as it is). Without the high-end Power4 and the embedded markets, there wouldn't be a desktop PPC today.

Brian

alt='scissors'

sigh

Dvorak has proved time and again he is a idiot

Apple is very happy with PowerPC and IBM mainframe division (you know that part of IBM that signs deals for 25 years let me say that again YEARS) is not going to move from POWER anytime, ever, notachance, when hell.....

why buy Connectix ?

If you have been to microsoft they where, and still are, big users of VMware which allows their sales people to be given a disk image for seeqel server and demo gods smile on them... (equally they use it like everyone else to test software in a sandbox)

they took one look at the virtualization market and wanted a chunk....

Q: how does MS get "innovative" technology ?
A: BUY

Q: how do you run 64bit apps and provide 32bit apps a (broken) operating environment without switching whole machine to 32bit
A: ask AMD....

Email address supplied

ยต


Share this:

Comments

There are no comments submitted yet. Do you have an interesting opinion? Then be the first to post a comment.

Advertisement
Subscribe to the INQ Newsletter
Sign-up for the INQBot weekly newsletter
Click here to sign up Existing user
Advertisement
INQ Poll

Christmas computer sales

Will you be buying a new computer this Christmas?