Poll: Primary D version

[retard]

Sat, 22 May 2010 16:25:55 -0400, Nick Sabalausky wrote:

> "retard" <re at tard.com.invalid> wrote in message
> news:ht9atu$rop$1 at digitalmars.com...
>> Sat, 22 May 2010 13:59:34 -0400, Nick Sabalausky wrote:
>>>
>>> Most apps don't need native x86_64. Only things that really push the
>>> limits of CPU/memory utilization need it, which, aside from bloatware
>>> (which admittedly is at epidemic levels lately), is really only a
>>> minority of apps. For the rest, if it already runs fine on 32-bit,
>>> then the same exec on a 64-bit machine is only going to run better
>>> anyway, and if is already ran fine before, then there's no problem.
>>
>> You're suffering Stockholm syndrome there. Not having a functional
>> 64-bit compiler isn't a positive feature.
>>
>>
> I never said it was. All I said was that most apps don't need native
> 64-bit versions. Don't go pulling out strawmen.

Sorry for pulling out that, but I thought the claim "most apps" was a bit 
overoptimistic. If D is The next gen language, it probably also should 
solve the next generation of problems. I don't see much point in 
rewriting notepad, mspaint or solitaire in D. If you only need to deal 
with a small amount of data, why use native low-level languages? The fact 
is that resource usage will grow and artificial limitations (32-bit code) 
just makes the language irrelevant a lot faster.

Another problem with x86 code is that you need to install all kinds of 32-
bit libraries on a x86-64 (Linux) system. You also don't have the full 
2.5 - 3.7 GB (depending on of RAM available for processes, the limit is 
something like 2 or 3 GB depending on the OS settings [1] (in some cases 
you need to assume the user has only allowed 2 GB for user mode 
processes). So in reality you could probably have even less than 2 GB 
available. Is that a problem? Yes, it is a serious problem in 
professional audio/video/photo applications, soon games (huge game 
worlds, complex SVM/ANN AI), and all kinds of servers.

> Take a 32-bit executable optimized for i386 or i586, that runs
> acceptably well on a 32-bit system (say, a P4, or even a P4-era
> Celeron). Take that same binary, put it on a 64-bit system (say, your
> Core i7). It will run *at least* at fast, most likely faster.

Yea, it will run faster, but who said the original application ran fast 
enough? CPU demanding applications never run fast enough. The 
applications tend to require more and more resources. It seems the x87 
instructions (i386/586) have 5-6x larger latency than SSE2+ and SSE2+ has 
2-4x greater throughput. Combined, that could mean 20x slower loops.

> Could it be made even faster than that with a 64-bit-native recompile?
> Sure. But if the 32-bit binary already ran acceptably well on the 32-bit
> system, and even faster on the 64-bit system, then who gives a shit?
> 
>> Guess how much a 64-bit system with 4 GB of RAM costs these days - a
>> quick search gave me the number $379 at
>>
>>
> Guess how much more that costs me than using my 32-bit system that
> already does everything I need it to do? $379.

Sure. And I have to admit I don't really know what's your target 
audience. It might even be 8086 systems since IIRC dmd/dmc support old 16-
bit dos environments.

But most commercial applications aren't geared towards Your 32-bit 
system. There's a good reason - people do upgrade their systems at least 
once in 5 years (x86-64 appeared 7 years ago..). Your system *will* 
physically break at some point and you have to replace it, probably with 
a faster one, because they won't be selling compatible parts anymore. 
Computers have a limited life time. Ordinary people don't lubricate their 
fans or replace bad capacitors themselves.

You can find used parts, but those are more expensive than new ones. For 
example a used 128MB/SDRAM-100 module typically costs as much as a 1GB/
DDR2-800 here. Budget GPUs for the PCI bus cost 4x as much as similar PCI 
Express cards. A 750GB PATA disk costs as much as a 1500GB SATA-2 disk. 
And let's be honest, $379 isn't that much - if you only upgrade the cpu
+mobo+ram+gpu, it's closer to $100-150. If you can't afford that much 
once in 5 years, you should stop developing software, seriously.

If Your application doesn't require new hardware, the 3rd party software 
forces you to upgrade. For example, recently I noticed that the Ati/
Nvidia GPU control panel requires a .NET version that is not available 
for Windows 2000 (and that's not the only program not working on Windows 
2000 anymore..). So I must buy a new operating system.. but people can't 
legally sell their used OEM Windows without also selling me their 64-bit 
machines =) And I can't buy a new Windows XP/Vista license, only Windows 
7 available on stores. So basically I'm forced to also upgrade the 
hardware.

[1] http://www.brianmadden.com/blogs/brianmadden/archive/2004/02/19/
the-4gb-windows-memory-limit-what-does-it-really-mean.aspx