Poll: Primary D version

[Nick Sabalausky]

"retard" <re at tard.com.invalid> wrote in message 
news:ht9n8n$rop$4 at digitalmars.com...
> 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 never said D or DMD shouldn't support x64, hence, yea, I agree that it 
should support 64-bit to, as you say "solve the next generation of 
problems". I just think that, for most apps, it's silly for someone to feel 
that they must have a 64-bit binary.


> I don't see much point in
> rewriting notepad, mspaint or solitaire in D.


For someone who seems to believe so strongly in "out with the old, in with 
the new", it seems rather odd that you expect apps along the lines of 
notepad, mspaint, etc to all stick around forever and with the same old 
langauge.


> If you only need to deal
> with a small amount of data, why use native low-level languages?


1. Why not? There's nothing about smaller apps that necessitates anything 
like a VM.

2. To avoid pointless bloat. Just because some people have a gajillion cores 
and petabytes of ram doesn't mean there's any reason to settle for a notepad 
that eats up a third of that.

3. I know this isn't in line with the current trendiness-compliant 
viewpoints, but I'd much rather find a good language and be able to stick 
with it for whatever I need than constantly bounce around a hundred 
different languages for every little thing.


> The fact
> is that resource usage will grow and artificial limitations (32-bit code)
> just makes the language irrelevant a lot faster.
>


Why do you still imply that I've advocated keeping D/DMD 32-bit-only?

> Another problem with x86 code is that you need to install all kinds of 32-
> bit libraries on a x86-64 (Linux) system.


If your Core i7 system with 24 GB RAM has any trouble keeping around the 
32-bit libs in addition to 64-bit ones, then you got royally screwed over. 
But if you're talking about the bother of installing the 32-bit libs, well, 
that's Linux for you (Not that I'm a fan of any particular OS).


> 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.


I only have 1 GB installed, so I couldn't care less. (Although I could have 
sworn I had 2 GB. Weird...Maybe I moved the other stick over to my Linux box 
when I built it...)


> 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.
>


Video: By what I admit is a rather big coincidence, I have some video 
processing going on in the background right as I type this. Seriously. I do 
video processing on this machine and I get by fine. Obviously, I would want 
to get a 64-bit multi-core with gobs of RAM if I were doing it 
professionally, but I think you're seriously underestimating the 
capabilities of P4-era hardware.

Games: I'll put it this way: I bought a Wii, and not a 360 or a PS3, 
specifically because I don't give a rat's ass about game graphics that are 
anything more than, frankly, Gamecube or XBox 1 level. One of my favorite 
games is Megaman 9. So you can't tell me that all that fancy hardware is, or 
will ever be, necessary for games. It is necessary for *some* types of 
games, but these days that's only because developers like Epic are in bed 
with the hardware manufacturers and refuse to care one bit about anyone who 
isn't a High-Def graphics whore.

Also, I hate playing games at a desk (or on a laptop, for that matter), so I 
almost always play on a console system, and therefore don't need my PC to 
play games anyway. A lot of gamers feel the same way (and there's plenty of 
other issues with games-on-a-PC too, like rootkit DRM and lack of 
second-hand-market). And for that matter, most PC users never go anywhere 
near the sorts of games that require fancy hardware anyway. So again, not a 
particularly compelling argument.

Servers: Sure, for a lot of servers. But that's only a subset of software in 
general. Besides, half of the sites out there run on notably slow platforms 
like PHP and Python, so really, there's lot of people who clearly don't care 
about speed even for a server.

>> 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?


I did when I said "**that runs acceptably well** on a 32-bit system". And 
contrary to popular belief, "software that runs acceptably well on a 32-bit 
system" is far from unreasonable. Most of the software I use runs acceptably 
well on my 32-bit system (a Celeron, even). And as for the software I use 
that doesn't run particularly well on this system (like FireFox 2), well, I 
can still get by fine with it, and there are always alternatives out there 
that do run much faster (meaning it's not an issue with my hardware being 
too slow), but that I just don't use because they have other drawbacks (like 
Chrome) and speed isn't always my top priority in choosing an app (or in 
choosing hardware, for that matter).


> 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.
>


I used to have a double-speed CD burner. Got it way back when they were 
$200-$300 and triple-/quad-speeds didn't exist. Used to set up a burn, get 
something else useful done for half an hour, and then it'd be done. Later 
on, I got one of those super-fast burners, something like 32x, maybe 50x or 
so, I don't remember. God was it fast by comparison. Practically instant, it 
seemed. Soon after, I realized that it hardly ever made any real difference 
at all in overall time savings.

Sometimes a 20x speed-up matters, sure. But not as often as people think. 
When it improves responsiveness, that's when it usually matters. When it 
improves something that's already inherently slow, it doesn't always matter 
quite as much as people think it does.

>> 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.
>


I don't know about DMC, but DMD, and even the D spec itself, doesn't do 
16-bit. (A number of embedded developers (low-level, naturally) have voiced 
disappointment with that.)

> 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.


If your computers break down in just five years, you're buying crap.


> (x86-64 appeared 7 years ago..)


Which hardly counts, since at the time it cost an arm and a leg and nothing 
used it. Basically, your average Joe was definitely *not* buying it.


> Ordinary people don't lubricate their
> fans or replace bad capacitors themselves.
>


Neither do I.

> 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.
>

First of all, I have gotten upgrades to this machine. Replaced the CD burner 
with a dual-layer DVD burner. Constantly add bigger hard drives (I admit, I 
can never have enough HDD space). Got a Bluetooth dongle to mess around with 
the Wii remote. Got a video capture card. Stuck in one of those memory card 
readers that fits in a 3.5" floppy bay (also have a 3.5" floppy drive, of 
course ;) ). Replaced my GeForce 2MX with a cheap Radeon 9200SE (IIRC) so I 
could mess around with pixel shading (which turned out to be a waste, since 
I never did get around to it).

But you're still sidestepping the bigger picture here: If my computer is 
working fine for me, does what I need it to do, why in the world should I be 
expected to replace it at all? (Just to please some damn gear-heads, or lazy 
developers?) Especially if I have other things to spend money on that 
actually *do* matter.

> 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 what? Most 3rd party software is crap anyway. And as far as OEM software 
goes (and I'm definitely including both ATI and NVIDIA, as well as Toshiba, 
HP, and others, all from personal experience), well, I *would* say OEM 
software is always crap, but "crap" is far too kind a word for it. There's 
crap software, and then there's OEM software. And I've long been saying that 
hardware companies don't know a damn thing about software.

Besides, ever since XP came out, Win2k was primarily just used by 
businesses. And MS-businesses always flock unquestioningly to the latest 
versions within about a year of release, and since Win2k, there's been XP, 
2k3, Vista, 7, and there may have been another server one I'm forgetting. 
*I* probably wouldn't have yanked Win2k support, but it's not a great 
example of software forcing a hardware upgrade.


> 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.
>

I don't know first hand, but I keep hearing [non-MS] people claiming that 
Win7 runs faster than XP even on XP-era hardware.