ISO 64 bit tablet PC (for comp.arch work)
Andy...@gmail.com
* comp.arch because "that's my home", and the PC in question will
be used for computer architecture work
* also because I think that comp.arch should discuss
implications of tablets, 32->64 transition, etc.
* microsoft.public.windows.tabletpc because I am asking tablet PC
questions
* microsoft.public.windows.tabletpc.developer because my needs are
similar to those of a high end developer
* vmware.guest.misc because it is vmware related
---+ BRIEF: I am looking for advice/recommendations for what Tablet
PC I should purchase.
My requirements/desires:
* must be x86
* must be 64-bit capable - e.g. must be able to run instructions
such as 64 bit load to RAX
* should be a Tablet PC
* may run a 32 bit Tablet PC OS, if a 64-bit Tablet PC OS, and
associated device drivers, cannot be found
* must be able to run 64-bit code under VmWare or the
equivalent, if the main OS is 32-bit
* must run Microsft OSes such as Windows, Vista
* WHY: AFAIK there is no useful tablet PC support on Linux
* also, I need to connect to Intel's Windows ecosystem
* highly desirable to be able to run Linux in a virtual machine.
* should be a Tablet PC with a pen/stylus
* I like writing, not just touchscreen
* display must be at least 1024x768
* should be 1200x1024, or larger
* highly desirable if tablet can use LCD and external video as
independent display surfaces,
and can drive 1200x1024 or larger externally, even if limited
to 1024x768 on on LCD
I have had trouble finding such tablet PCs. Many tablet PCs, although
with 64-bit processors, are only available with 32-bit OSes, probably
because of device driver availability.
Any advice/pointers appreciated. Please email pcsearch@patten-
glew.net
---+ Detail
---++ BACKGROUND
I do computer architecture work, instruction set and microarchitecture
simulations. I like to work on my laptop, particularly when not
connected to the Internet. For the past few years I have been able to
get away with a 32-bit processor -- I have 32-bit simulators that can
simulate 64-bit stuf, albeit slowly -- but more and more I need to
have a 64-bit microprocessor in my laptop.
---++ PROBLEM: Intel's IT department does not support 64-bit
laptops.
Last I looked, Intel IT did not support 64-bit client OSes at all, but
my group was able to buy 64-bit clients, install our own 64-bit OSes,
and run them "unsupported" by IT. (E.g. if malware breaks in, we are
fined.)
But apparently our budget only allows us to buy "desktop" clients.
Apparently we cannot spend our own money to buy 64-bit laptops.
Apparently Intel IT is in the process of deploying 64-bit capable
laptops, but only running 32-bit OSes. Unfortunately, there appears to
be a rotation or schedule as to who gets upgraded to 64-bit, and I am
not on the schedule for such an upgrade any time soon.
I can do 64-bit work on our non-laptop systems. But I really want to
be able to work on my laptop. (When I am asked "Why haven't you
written a 64-bit simulator", my answer is "the machine I work on is 32-
bits".)
---++ WORKAROUND and RELATED ISSUES: Because Intel IT won't provide me
a 64-bit laptop, I am considering buying one for myself.
I will work through the issues of getting it connected to the Intel
network.
---+++ Tablet
However, in part because it is possible that I may end up not being
able to connect a personally owned laptop to the Intel network, I am
only interested in purchasing a computer I would use for my own
work. I am not interested in a laptop; I am only interested in
spending my own money on a convertible Tablet PC. (I have compromised
a bit: if I did not need a 64-bit mobile device at work, I wouldn't be
buying a PC at all; instead I would be spending my money on a smart
phone.)
There are a few Tablet PCs that have 64-bit Core 2 Duo processors.
However, so far whenever I look closely I always find that they are
only available with 32-bit OSes. I expect that this is because the
device drivers are only available in 32-bits.
==> if you know of a Tablet PC that runs 64-bits, with 64-bit
processor and OS, please tell me. I.e. one where I can install 64-
bit Vistual C++, and compile 64 bit code.
If there are any 64-bit Tablet PC OSes out there, it would solve the
remaining issues.
---+++ Virtual Machines
One possibility could be to run a 32-bit host OS, and then install
VmWare to run a 64-bit guest OS. However, last time I checked (last
year) VmWare could not do this. On our desktop 64-bit systems, we
installed 64-bit host OSes, which required that we not be supported by
IT, and then installed 32-bit VmWare guests, so that we could run 32
and 64 bit code on the same system. We were unable to run 64-bit
guests on 32-bit hosts.
I have since heard rumors that VmWare can now run 64-bit guests on 32-
bit host OSes. The sources are reputable, but I cannot find this
documented on VmWare's web pages. Since installing OSes on VmWare,
or native hardware, can be a pain, I was hoping that somebody could
confirm or deny this, so that I can avoid wasting time find out the
hard way.
Q: can VmWare run 64-bit guests on a 32-bit host OS, on a 64-bit
capable microprocessor?
I.e. if I buy a Tablet PC that only has a 32-bit OS, because of the
aforementioned device driver issues, but which has a 64-bit capable
microprocessor, can I install a 64-bit guest OS under VmWare?
---+++ Display Size
I like lots of pixels. Even on a small Tablet PC LCD, but especially
if the tablet PC can drive an external monitor.
The last Tablet PC I had (a Toshiba) could not drive the external
video independently of the tablet LCD. I.e. the external display
resolution had to be the same size as the tablet LCD.
On my current Intel supplied laptop, a Thinkpad T43p, I have grown
attached to having independent external and internal video. E,g. at
the moment I am sitting in front of a 1600x1200 external LCD, while my
laptop LCD is displaying 1400x1050 and is displaying "background"
information such as the task manager.
The various Tablet PC specs are not very clear as to whether they
support this sort of external display. The sales support question-
answerers all seem puzzled by what I ask for.
Therefore, I ask these newsgroups which tablet PCs support this sort
of indepedent internal and external displays.
---++ Conclusion
I may be searching for a product that does not exist. But I can
hope...
If I can find a Tablet PC running a 64-bit OS, most of my needs will
be met.
If VmWare can run 64 bit guests on top of a Tablet PC running a 32 bit
OS on a 64 bit CPU, most of my needs will be met.
This would leave only the display issue.
If necessary, I will fall back to using 1024x768 on a tablet - but I
know there are 1200x1024 TabletPCs. (Unfortunately, the only one I
have asked deeply about, a Toshiba tablet, says that only 32-bit Vista
can use the tablet.)
I don't know of any tablet with the independent external and internal
display. But I can give up on that.
I guess 64 bit is my only hard requirement.
Terje Mathisen
> ---+ BRIEF: I am looking for advice/recommendations for what Tablet
> PC I should purchase.
>
> My requirements/desires:
> * must be x86
> * must be 64-bit capable - e.g. must be able to run instructions
> such as 64 bit load to RAX
I.e. any recent Intel (or AMD!) cpu.
> * should be a Tablet PC
> * may run a 32 bit Tablet PC OS, if a 64-bit Tablet PC OS, and
> associated device drivers, cannot be found
> * must be able to run 64-bit code under VmWare or the
> equivalent, if the main OS is 32-bit
This does work.
[big snip]
> I have since heard rumors that VmWare can now run 64-bit guests on 32-
> bit host OSes. The sources are reputable, but I cannot find this
> documented on VmWare's web pages. Since installing OSes on VmWare,
> or native hardware, can be a pain, I was hoping that somebody could
> confirm or deny this, so that I can avoid wasting time find out the
> hard way.
>
> Q: can VmWare run 64-bit guests on a 32-bit host OS, on a 64-bit
> capable microprocessor?
This does work very nicely, VMware 6 (6.02 is the current release) does
support 64-bit client OSs ona 32-bit host, as long as the CPU provides
the requisite virtualization support.
> ---+++ Display Size
>
> I like lots of pixels. Even on a small Tablet PC LCD, but especially
> if the tablet PC can drive an external monitor.
I'm using 1920x1200 + 1600x1200 on a pair of external monitors, with
XP-64 as my primary (host) OS and XP-32, Vista-64 and Linux-64 as client
machines, but unlike you I haven't fallen in love with tablets; i.e.
this is a regular (Fujitsu-Siemens C250) laptop with 4 GB ram.
It took me a few weeks before I got everything to work nicely with
XP-64, i.e. Nvidia's graphics drivers has/had a memory leak of about 20
kB/second, fortunately in an optional device driver which web searches
told me could be disabled. I also had troubles getting both external
monitors (via a port replicator) to be active at once, I finally had to
disable some BIOS video autosense parameters to make it work, and when
switching from laptop screen only (1680x1050) to the docked
configuration I have to manually disable monitor two, then use Fn+F10 to
switch (in order) to second (analog VGA) monitor only, analog+internal
in clone mode, then DVI external only, before I can close the laptop lid
and manually re-enable the VGA-connected second screen.
I don't need to do this very often though, because I've got exactly the
same setup at work and at home.
> On my current Intel supplied laptop, a Thinkpad T43p, I have grown
> attached to having independent external and internal video. E,g. at
> the moment I am sitting in front of a 1600x1200 external LCD, while my
> laptop LCD is displaying 1400x1050 and is displaying "background"
> information such as the task manager.
>
> The various Tablet PC specs are not very clear as to whether they
> support this sort of external display. The sales support question-
> answerers all seem puzzled by what I ask for.
My guess is that you'll find close to zero support for external monitors
with the tablet interface, i.e. you might have a tablet while traveling
and effectively a regular laptop when sitting at your desk.
Terje
PS. A few more pointers:
Visual Studio defaults to NOT include the 64-bit tools, _even_ when the
host machine is 64-bit Windows!
On both machines where I have tried this, VMware wouldn't handle 64-bit
clients initially because the cpu virtualization support was by default
disabled in the BIOS.
I've had a couple of hard system crashes (two in 2 weeks) which both
required a full rebuild of my primary machine, and they both seemed to
occur just as I was starting a VTune sampling run. This was while using
XP-32 as the host OS, and it was the main reason I switched to a new
laptop much sooner than I had intended to.
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Andy...@gmail.com
(http://rogue.colorado.edu/pin/), y'all might be interested to learn
that the last straw that has compelled me to go shopping for a 64 bit
laptop, since Intel IT will not provide one, is Pin:
My simulators run fine - I can simulate 64 bit code on my old 32 bit
laptop. Slower than on a true 64 bit processor, but good enough for
debugging.
However, more and more I am using Pin to generate workload samples for
simulation. And Pin cannot run 64 bit apps on 32 bit processors.
That's not all that unreasonable a limitation. But it is compelling me
to go shopping for a 64 bit laptop earlier than Intel IT thinks I need
one.
---
The real moral for comp.arch is about the speed of transitions such as
32->64 bits: How long has 64 bits been available? And yet I still
don't have it in the PC I work on? If Intel IT lags so much, how can
you expect corporate IT or individual users to adopt new technology?
Glews observation:
IT departments are barriers to innovation and adoption.
(Except for technologies, such as virtualization or RAS or
manageability, that help IT departments do their job.
Corollary: it is easier to talk to a few IT departments than it is to
talk to lots of consumers. So it is easier to justify innovations
that make IT departments happy, rather than justify innovations that
make individuals happy.
This is just another flavor of Ward Christenson's "Innovator's
Dilemma".
---
There are similar issues with every new processor. Intel people
always complain that OS folks, such as Microsoft, are slow to adopt
and tune for new processors. But I'm totally on Microsoft's side
here: it's just plain easier to test and tune and evaluate your code
on the computers you use every day.
Sure, there will be dedicated people who are willing to test and
evaluate code for new processors on simulators. Or on special lab
machines. But there are fewer such people than there are generic
software developers.
You get into situations where the generic software developers churn
out untuned code, and the dedicated people who are using special
development vehicles are constantly playing catchup.
If you want code to be tuned and evaluated for new processors, you
need to make sure that as many software developers as possible are
using your processors on a daily basis. And even then there is a time
delay.
Andy...@gmail.com
> required a full rebuild of my primary machine, and they both seemed to
> occur just as I was starting a VTune sampling run. This was while using
> XP-32 as the host OS, and it was the main reason I switched to a new
> laptop much sooner than I had intended to.
>
Terje's comment makes me wonder:
Is there natural selection pressure that increases the chances of such
bugs?
Since bugs like this often cause extra sales?
Del Cecchi
"comp...@patten-glew.net" <Andy...@gmail.com> wrote in message
news:63e17f44-1a3e-44fa...@p69g2000hsa.googlegroups.com...
> Given that I recently highly recommended "Pin" for comp.arch work
> (http://rogue.colorado.edu/pin/), y'all might be interested to learn
> that the last straw that has compelled me to go shopping for a 64 bit
> laptop, since Intel IT will not provide one, is Pin:
>
> My simulators run fine - I can simulate 64 bit code on my old 32 bit
> laptop. Slower than on a true 64 bit processor, but good enough for
> debugging.
>
> However, more and more I am using Pin to generate workload samples for
> simulation. And Pin cannot run 64 bit apps on 32 bit processors.
>
> That's not all that unreasonable a limitation. But it is compelling me
> to go shopping for a 64 bit laptop earlier than Intel IT thinks I need
> one.
>
> ---
>
> The real moral for comp.arch is about the speed of transitions such as
> 32->64 bits: How long has 64 bits been available? And yet I still
> don't have it in the PC I work on? If Intel IT lags so much, how can
> you expect corporate IT or individual users to adopt new technology?
The real moral for comp.arch is the slow progress when a monopoly
supplier is dealing with a large installed base that is indifferent to
the transition. This applies to microsoft, Intel, and your IT
department.
The only reason that there is a 64 bit x86 is because AMD needed a lever.
Microsoft has no real reason to support 64 bits other than perhaps to
keep the government off their backs by supporting AMD. Your IT
department has no interest in anything that will make their job harder
unless there is considerable user demand leading to executive edict.
As deep throat said in the movies "follow the money".
(snip)
Terje Mathisen
>> 32->64 bits: How long has 64 bits been available? And yet I still
>> don't have it in the PC I work on? If Intel IT lags so much, how can
>> you expect corporate IT or individual users to adopt new technology?
>
> The real moral for comp.arch is the slow progress when a monopoly
> supplier is dealing with a large installed base that is indifferent to
> the transition. This applies to microsoft, Intel, and your IT
> department.
>
> The only reason that there is a 64 bit x86 is because AMD needed a lever.
I disagree.
> Microsoft has no real reason to support 64 bits other than perhaps to
> keep the government off their backs by supporting AMD. Your IT
I believe that's wrong.
> department has no interest in anything that will make their job harder
> unless there is considerable user demand leading to executive edict.
IMHO the key/sufficient reason for MS to develop a 64-bit Windows for
AMD-64 was quite simple:
Some very important customers require more than about 2GB of available
user memory, andif they can't have it, they will simply switch to
unix/linux.
This goes for all the server vendors, as well as workstations used for
both normal engineering/simulation work and for financial modeling.
It is significant that XP-64 first turned up in the form of the
server-only Windows-2003.
>
> As deep throat said in the movies "follow the money".
Always a good bet, particularly when/if Wall Street companies are big
buyers of 64-bit systems.
Terje
Terje Mathisen
> Given that I recently highly recommended "Pin" for comp.arch work
> (http://rogue.colorado.edu/pin/), y'all might be interested to learn
> that the last straw that has compelled me to go shopping for a 64 bit
> laptop, since Intel IT will not provide one, is Pin:
>
> My simulators run fine - I can simulate 64 bit code on my old 32 bit
> laptop. Slower than on a true 64 bit processor, but good enough for
> debugging.
>
> However, more and more I am using Pin to generate workload samples for
> simulation. And Pin cannot run 64 bit apps on 32 bit processors.
You might be able to do so running a 64-bit OS as a VMware client under
a 32-bit host OS.
> The real moral for comp.arch is about the speed of transitions such as
> 32->64 bits: How long has 64 bits been available? And yet I still
> don't have it in the PC I work on? If Intel IT lags so much, how can
> you expect corporate IT or individual users to adopt new technology?
You cannot.
>
> Glews observation:
> IT departments are barriers to innovation and adoption.
IT departments are almost universally measured by their "Service
Level/Uptime" performance, which means that it is in their best interest
to keep things as stable as humanly possible.
Replacing the entire OS infrastructure of a big organization is not
something you want to even contemplate before you're forced to do it.
> (Except for technologies, such as virtualization or RAS or
> manageability, that help IT departments do their job.
Right.
> If you want code to be tuned and evaluated for new processors, you
> need to make sure that as many software developers as possible are
> using your processors on a daily basis. And even then there is a time
> delay.
And even there you have heavy pressure to develop code that's compatible
with as many user machines as possible.
Case in point:
I have spent some weeks writing/optimizing what I believe is the worlds
fastest Ogg Vorbis decoder, it uses nothing but plain SSE in 32-bit mode
(and SSE2 in 64-bit mode, since that's guaranteed to be available).
It is significantly faster than the SSE3-based code which was my
benchmark target.
By staying within the SSE-only opcodes, I've ensured that effectively
all existing x86 machines will be able to run it, right?
Terje
Del Cecchi
"Terje Mathisen" <terje.m...@hda.hydro.com> wrote in message
news:Ju6dnb6yn6wwsdja...@giganews.com...
> Del Cecchi wrote:
>> "comp...@patten-glew.net" <Andy...@gmail.com> wrote in message
>>> The real moral for comp.arch is about the speed of transitions such
>>> as
>>> 32->64 bits: How long has 64 bits been available? And yet I still
>>> don't have it in the PC I work on? If Intel IT lags so much, how can
>>> you expect corporate IT or individual users to adopt new technology?
>>
>> The real moral for comp.arch is the slow progress when a monopoly
>> supplier is dealing with a large installed base that is indifferent to
>> the transition. This applies to microsoft, Intel, and your IT
>> department.
>>
>> The only reason that there is a 64 bit x86 is because AMD needed a
>> lever.
>
> I disagree.
On what grounds? Intel's official 64 bit solution was Itanium. And they
denied having any interest in 64 bit X86 until AMD's success forced their
hand. Had it not been for AMD, x86 would have died at 32 bits.
>
>> Microsoft has no real reason to support 64 bits other than perhaps to
>> keep the government off their backs by supporting AMD. Your IT
>
> I believe that's wrong.
So what was Microsoft's motivation? I am cynical enough to know that
they weren't going to waste resources going to 64 bits just for the
benefit of the customer. Loss of market share to Linux might have done
it. Eventually they would have supported Windows of some type on
Itanium. I guess they did. But they had to if Intel and HP strategic
direction for 64 bits was Itanium.
>
>> department has no interest in anything that will make their job harder
>> unless there is considerable user demand leading to executive edict.
>
> IMHO the key/sufficient reason for MS to develop a 64-bit Windows for
> AMD-64 was quite simple:
>
> Some very important customers require more than about 2GB of available
> user memory, andif they can't have it, they will simply switch to
> unix/linux.
And what would they run this linux on if there were no 64 bit X86? And
was that a sufficient club to get microsoft to support it?
Terje Mathisen
> "Terje Mathisen" <terje.m...@hda.hydro.com> wrote in message
> news:Ju6dnb6yn6wwsdja...@giganews.com...
>> Del Cecchi wrote:
>>> The only reason that there is a 64 bit x86 is because AMD needed a
>>> lever.
>> I disagree.
>
> On what grounds? Intel's official 64 bit solution was Itanium. And they
OK, I agree:
If Itanium had been the success Intel intended, then AMD wouldn't have
had the same opportunity to hijack the x86 architecture the way they did.