Re: HLA malloc problem
- From: dave <spamtrap@xxxxxxxxxx>
- Date: Sun, 13 May 2007 20:46:04 -0700
Servers seem to like 64-bit environments. I think there are two
reasons why I prefer to use a 64-bit server: 1) Larger addressable
memory, but I personally don't run SQL server or something that needs
it. 2) Most viral code that attempts to get too far into the OS have
problems working on the 64-bit versions of Windows Server.
Maybe games will be the user environment that pushes 64-bit Windows
into the mass market, albeit slowly at first. If screens require a
lot of preprocessing before they are transferred to the video cards,
they may begin to use the SMP systems to dedicate processor(s) to
doing this in large memory systems. I don't know how much games will
change. What if they begin to offer the gamer the opportunity to use
a jpg of themselves as one character and the game tries to make his
actions more realistic? It may be possible though I think ILM does
this for movies and it takes days to do a few minutes. One of the
days we may have the equivalent capability in our desktops and
notebooks.
David
On 13 May 2007 16:37:06 -0700, "rhyde@xxxxxxxxxx"
<spamtrap@xxxxxxxxxx> wrote:
On May 13, 1:59 am, Branimir Maksimovic <spamt...@xxxxxxxxxx> wrote:
Situation is bit different now, as 64 bit OS-es are already there.
As your next sentence demonstrates, you *are* aware that 32-bit OSes
existed prior to Win95 appearing. Yet the world's developers didn't
switch to 32-bit coding until Win95 appeared. And because they didn't
switch, neither did the PC population.
And then 32 bit support on unix was much earlier then 1995.
(sco unix)
And others, for that matter. But no one was using those OSes, just
like few people are using the 64-bit OSes today.
But I have to say something else: transition from 16 to 32 bit
was necessary because of memory limitation of 16 bit cpu-s.
Now we actually don't have any motivation to move to 64
bit.
Sure, this is a good reason for why developers jumped onto the 32-bit
bandwagon once Win95 appeared, but the bottom line is that until the
user base switched, there was really no impetus for the developers to
switch.
But, I had worked first on 64 bit sparcs, then my current shop
switched to 32 bit intels as cheaper and more efficient solution
for our needs, and there was not any real advantage in
64 bit computing. Now we get linux customers with
64 bit intel computers but default setup they get is 64 bit
machine with 2gb of ram. :)
The customers you're talking about are not the ones that will drive
the switch to 64-bitness. We're talking about the mass population
here. Until they switch, a developer is *severely* limiting their
market by writing code that requires a 64-bit OS for proper operation.
For some niche markets, this is great. But I still argue that worrying
about writing 64-bit applications is a bit premature at this point.
We moved our software to be 64 bit then again, but without
any real need. I see 64 bit programs as disadvantage
as they take more space and no real performance benefits.
Yes. We're still waiting for the "killer app". There are some apps
that absolutely need the memory space (video editors and renderers and
certain scientific apps, for example), but these are niche markets.
But if I want to acompany our software with asembler code,
on linux, I have to use 64 bit assembler as 32 bit one will not
link to 64 bit object files.
You are a special case. Would you argue that because your particular
customers need 64-bit software that *everyone* learning assembly
langauge should use "64-bitness" as a criterion for what assembly
language they learn?
Windows is different situation as I have no any intentions
to make 64 bit sw there as I don;t know what to do with
2gb of address space, let alone 4gb which are available on
64 bit versions, for 32 bit processes.
Would someone who has decided to pick up assembly language know what
to do with this? That's the question that was asked in this thread.
Anyway until default setup for intel boxes exceeds 4gb
of ram and we make bloatware that will use more then that,
(there are apps that are always ram hungry)
I don;t see any real need for 64 bit programs.
I won't say that I don't see the need for 64-bit programs and I
certainly won't say that there won't be a need for them in the future.
What I will say is that if you're learning assembly language today,
and you expect to use those skills on projects you'll be working on,
then learning 64-bit coding is not that important if you expect to be
able to share your code with lots of other people. If you're going to
write code for your own box or for a very select number of people who
are running the OS you write your code for, then by all means go 64
bits. I just don't see this as an important assembly language
selection criterion at this point.
I still estimate that in five years the need for 64-bit skills will be
important. Not today, except in niche products.
hLater,
Randy Hyde
.
- Follow-Ups:
- Re: HLA malloc problem
- From: rhyde@xxxxxxxxxx
- Re: HLA malloc problem
- References:
- Re: HLA malloc problem
- From: cocoer
- Re: HLA malloc problem
- From: randyhyde@xxxxxxxxxxxxx
- Re: HLA malloc problem
- From: Betov
- Re: HLA malloc problem
- From: Branimir Maksimovic
- Re: HLA malloc problem
- From: Charles Crayne
- Re: HLA malloc problem
- From: Branimir Maksimovic
- Re: HLA malloc problem
- From: rhyde@xxxxxxxxxx
- Re: HLA malloc problem
- From: Branimir Maksimovic
- Re: HLA malloc problem
- From: rhyde@xxxxxxxxxx
- Re: HLA malloc problem
- Prev by Date: Re: [Clax86list] HLA malloc problem
- Next by Date: Re: HLA malloc problem
- Previous by thread: Re: HLA malloc problem
- Next by thread: Re: HLA malloc problem
- Index(es):
Relevant Pages
|
