By: JasonB (no.delete@this.spam.com), May 14, 2007 6:35 pm
Room: Moderated Discussions
I didn't have time to address everything in my last post so I'll take a second bite of the cherry. :-)
Dean Kent (dkent@realworldtech.com) on 5/14/07 wrote:
---------------------------
>>In our case I don't actually have any urgent plans to make the software itself
>>64 bits. 4GB is actually enough for our software, at least for a while. (By
>>the time you get to over 2GB of data in our case the performance is the limiting
>>factor, not the available memory.) The problem is that we can't get close to 2GB
>>on a normal 32 bit Windows PC. The maximum possible project size available to the
>>user is constrained by the software's ability to access memory, whereas running
>>the same 32 bit software on a 64 bit OS the user is constrained by their own patience.
>
>While it may not result in development costs, it is likely that it results in support
>costs. Customers will complain about performance, and even if the answer is to
>upgrade - it still costs support time and effort.
Everything has a cost, yes. But not everything costs the same.
I can't speak for the general case but I know exactly how much time and effort and maintenance costs we have incurred in trying to deal with memory issues in 32 bit Windows. I also know every time we have had to choose a "more complex, slower, but more memory efficient" algorithm vs a "simpler, faster, but more physical or virtual memory intensive" algorithm in order to implement something. The customer never sees that as a direct cost, but it's in there -- new releases are delayed and new features are omitted because we spend more time implementing and debugging something than we otherwise would have, customer data is sometimes lost because a bug crept in there due to the complexity of the code, and so on.
Interestingly, the only support costs we have incurred so far from customers who are using 64 bit systems that were as a result of them using 64 bit systems occurred right at the beginning, when the driver for one of the hardware components wasn't yet mature, but by the time customers started using it the supplier had posted an update on their website so we simply asked them to download a new driver.
Currently customers with 64 bit systems are being unfairly punished because we still incur the costs of making the software work well on a 32 bit system, and not only does that make the code more buggy and slower to develop but it also means they are not getting the performance out of it that their systems are capable of. Maintaining 32 bit support definitely has costs, and I am very confident that the costs to the end users are far greater than the costs they might have incurred had they switched to a 64 bit system, even if that meant having a dedicated PC just to run our software and their regular PC for everything else.
>Nonetheless, the original point was (and is) that the average user does not need
>it, and therefore has little incentive to move to it. As you indicated, even those who *do* need it may resist.
Yes, but if you think the average user is only going to move to it when they need it, then I think the fact that my new notebook came with 64 bit Vista without even being advertised as doing so suggests that a lot of people will quite quickly have a 64 bit OS without even knowing it, let alone needing it.
Very few people actually need the computing power that they currently have, but that doesn't stop them from getting it, and I don't see why 64 bits will be any different.
Dean Kent (dkent@realworldtech.com) on 5/14/07 wrote:
---------------------------
>>In our case I don't actually have any urgent plans to make the software itself
>>64 bits. 4GB is actually enough for our software, at least for a while. (By
>>the time you get to over 2GB of data in our case the performance is the limiting
>>factor, not the available memory.) The problem is that we can't get close to 2GB
>>on a normal 32 bit Windows PC. The maximum possible project size available to the
>>user is constrained by the software's ability to access memory, whereas running
>>the same 32 bit software on a 64 bit OS the user is constrained by their own patience.
>
>While it may not result in development costs, it is likely that it results in support
>costs. Customers will complain about performance, and even if the answer is to
>upgrade - it still costs support time and effort.
Everything has a cost, yes. But not everything costs the same.
I can't speak for the general case but I know exactly how much time and effort and maintenance costs we have incurred in trying to deal with memory issues in 32 bit Windows. I also know every time we have had to choose a "more complex, slower, but more memory efficient" algorithm vs a "simpler, faster, but more physical or virtual memory intensive" algorithm in order to implement something. The customer never sees that as a direct cost, but it's in there -- new releases are delayed and new features are omitted because we spend more time implementing and debugging something than we otherwise would have, customer data is sometimes lost because a bug crept in there due to the complexity of the code, and so on.
Interestingly, the only support costs we have incurred so far from customers who are using 64 bit systems that were as a result of them using 64 bit systems occurred right at the beginning, when the driver for one of the hardware components wasn't yet mature, but by the time customers started using it the supplier had posted an update on their website so we simply asked them to download a new driver.
Currently customers with 64 bit systems are being unfairly punished because we still incur the costs of making the software work well on a 32 bit system, and not only does that make the code more buggy and slower to develop but it also means they are not getting the performance out of it that their systems are capable of. Maintaining 32 bit support definitely has costs, and I am very confident that the costs to the end users are far greater than the costs they might have incurred had they switched to a 64 bit system, even if that meant having a dedicated PC just to run our software and their regular PC for everything else.
>Nonetheless, the original point was (and is) that the average user does not need
>it, and therefore has little incentive to move to it. As you indicated, even those who *do* need it may resist.
Yes, but if you think the average user is only going to move to it when they need it, then I think the fact that my new notebook came with 64 bit Vista without even being advertised as doing so suggests that a lot of people will quite quickly have a 64 bit OS without even knowing it, let alone needing it.
Very few people actually need the computing power that they currently have, but that doesn't stop them from getting it, and I don't see why 64 bits will be any different.
Topic | Posted By | Date |
---|---|---|
Rock/Tukwila rumors | mas | 2007/05/05 11:59 AM |
Rock/Tukwila rumors | David Kanter | 2007/05/05 01:33 PM |
Rock/Tukwila rumors | Dean Kent | 2007/05/05 02:35 PM |
K8 vs Win64 timeline | anonymous | 2007/05/05 05:19 PM |
Yes, I misremembered... | Dean Kent | 2007/05/05 09:03 PM |
Rock | Daniel Bizó | 2007/05/06 01:34 AM |
Rock | Dean Kent | 2007/05/06 06:11 AM |
Rock/Tukwila rumors | Joe | 2007/05/06 10:24 AM |
Rock/Tukwila rumors | Dean Kent | 2007/05/06 10:49 AM |
Rock/Tukwila rumors | Linus Torvalds | 2007/05/06 11:09 AM |
Rock/Tukwila rumors | anon | 2007/05/07 12:32 AM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/07 08:36 AM |
Rock/Tukwila rumors | Michael S | 2007/05/07 09:06 AM |
Rock/Tukwila rumors | anon | 2007/05/07 08:48 PM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/08 05:45 AM |
Rock/Tukwila rumors | anon | 2007/05/08 04:30 PM |
Wow. (nt) | Brannon | 2007/05/08 05:16 PM |
Rock/Tukwila rumors | rwessel | 2007/05/08 08:48 PM |
Rock/Tukwila rumors | JS | 2007/05/08 09:07 PM |
Rock/Tukwila rumors | JS | 2007/05/09 05:44 AM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/09 04:35 AM |
Much ado about x | Michael S | 2007/05/09 08:39 AM |
Call it x86-64 | Linus Torvalds | 2007/05/09 09:27 AM |
(i)AMD64 | Michael S | 2007/05/09 11:16 AM |
(i)AMD64 | Linus Torvalds | 2007/05/09 11:29 AM |
(i)AMD64 | Groo | 2007/05/09 03:45 PM |
TIFNAA | anonymous | 2007/05/09 04:49 PM |
Inspired by FYR Macedonia? (NT) | Michael S | 2007/05/09 10:21 PM |
More likely... | rwessel | 2007/05/09 11:39 PM |
TIFNAA | Gabriele Svelto | 2007/05/09 10:57 PM |
(i)AMD64 | James | 2007/05/10 01:27 AM |
i86 | Dean Kent | 2007/05/09 11:30 AM |
(i)AMD64 | Max | 2007/05/09 12:28 PM |
wide86? long86? | hobold | 2007/05/10 04:05 AM |
x87 perhaps, it is one more. :) (NT) | Groo | 2007/05/10 04:50 AM |
x86+ | Dean Kent | 2007/05/10 07:44 AM |
Does it really matter? | Doug Siebert | 2007/05/10 08:10 AM |
let's stay with x86-64 for now, please | Marcin Niewiadomski | 2007/05/10 10:50 AM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/11 05:11 AM |
let's stay with x86-64 for now, please | rwessel | 2007/05/11 01:46 PM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/11 05:03 PM |
let's stay with x86-64 for now, please | Michael S | 2007/05/12 09:49 AM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/12 12:05 PM |
let's stay with x86-64 for now, please | Michael S | 2007/05/12 12:25 PM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/12 02:39 PM |
let's stay with x86-64 for now, please | JasonB | 2007/05/13 06:43 AM |
client consolidation | Michael S | 2007/05/13 07:37 AM |
let's stay with x86-64 for now, please | Tzvetan Mikov | 2007/05/13 02:44 PM |
let's stay with x86-64 for now, please | rwessel | 2007/05/14 01:42 PM |
What's your point? | Doug Siebert | 2007/05/11 01:56 PM |
What's your point? | Linus Torvalds | 2007/05/11 03:15 PM |
What's your point? | Doug Siebert | 2007/05/13 02:11 PM |
What's your point? | Dean Kent | 2007/05/13 06:04 PM |
What's your point? | JasonB | 2007/05/14 01:06 AM |
What's your point? | Dean Kent | 2007/05/14 06:20 AM |
What's your point? | JasonB | 2007/05/14 03:35 PM |
What's your point? | JasonB | 2007/05/14 06:35 PM |
What's your point? | Dean Kent | 2007/05/14 07:12 PM |
What's your point? | Dean Kent | 2007/05/11 05:06 PM |
What's your point? | Stephen H | 2007/05/13 12:55 AM |
Why didn't MS take advantage of PAE? | David W. Hess | 2007/05/13 07:37 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | Linus Torvalds | 2007/05/13 09:20 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | Dean Kent | 2007/05/13 09:49 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | David W. Hess | 2007/05/13 11:37 AM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 12:44 PM |
> 1 GB RAM on a 32-bit system | S. Rao | 2007/05/13 02:00 PM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 04:32 PM |
> 1 GB RAM on a 32-bit system | S. Rao | 2007/05/13 11:19 PM |
> 1 GB RAM on a 32-bit system | Linus Torvalds | 2007/05/13 02:46 PM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 04:23 PM |
> 1 GB RAM on a 32-bit system | JasonB | 2007/05/13 05:37 PM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/13 07:31 PM |
Windows manages memory differently | JasonB | 2007/05/14 12:50 AM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 07:56 AM |
Windows manages memory differently | rwessel | 2007/05/14 02:40 PM |
Windows manages memory differently | David W. Hess | 2007/05/14 03:07 PM |
Windows manages memory differently | rwessel | 2007/05/14 03:51 PM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 04:40 PM |
Windows manages memory differently | rwessel | 2007/05/14 05:09 PM |
Windows manages memory differently | Howard Chu | 2007/05/14 10:17 AM |
Windows manages memory differently | Jukka Larja | 2007/05/14 10:30 AM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 12:54 PM |
Windows manages memory differently | Howard Chu | 2007/05/15 02:35 AM |
Windows manages memory differently | Groo | 2007/05/15 06:34 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Matt Sayler | 2007/05/15 05:23 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Wes Felter | 2007/05/15 07:37 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Anonymous | 2007/05/15 09:49 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | anon2 | 2007/05/15 06:13 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Paul | 2007/05/13 02:40 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Peter Arremann | 2007/05/13 04:38 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Henrik S | 2007/05/14 02:31 AM |
The fragility of your argument | slacker | 2007/05/13 02:56 PM |
The fragility of your argument | nick | 2007/05/13 04:42 PM |
The fragility of your argument | Howard Chu | 2007/05/14 01:52 AM |
The fragility of your argument | Dean Kent | 2007/05/14 08:19 AM |
The fragility of your argument | anon2 | 2007/05/14 07:26 AM |
The fragility of your argument | Tzvetan Mikov | 2007/05/14 08:01 AM |
The fragility of your argument | Dean Kent | 2007/05/14 08:16 AM |
The fragility of your argument | Linus Torvalds | 2007/05/14 10:57 AM |
The fragility of your argument | JasonB | 2007/05/14 03:48 PM |
The fragility of your argument | Dean Kent | 2007/05/14 06:36 PM |
The fragility of your argument | Ricardo B | 2007/05/16 01:40 AM |
The fragility of your argument | Dean Kent | 2007/05/16 02:32 AM |
The fragility of your argument | Ricardo B | 2007/05/16 05:41 AM |
PS | Ricardo B | 2007/05/16 05:50 AM |
The fragility of your argument | Dean Kent | 2007/05/16 08:07 AM |
Modern web browsing | S. Rao | 2007/05/16 08:16 AM |
Aha! | Dean Kent | 2007/05/16 08:27 AM |
Aha! | Dean Kent | 2007/05/16 08:32 AM |
Aha! | S. Rao | 2007/05/16 09:34 AM |
The fragility of your argument | Ricardo B | 2007/05/16 09:00 AM |
The fragility of your argument | Vincent Diepeveen | 2007/05/16 09:10 AM |
The fragility of your argument | Paul | 2007/05/16 02:01 PM |
The fragility of your argument | Vincent Diepeveen | 2007/05/17 02:05 AM |
The fragility of your argument | anon2 | 2007/05/15 12:35 AM |
Splits vs page allocations? | Matt Sayler | 2007/05/15 06:33 AM |
What's your point? | Michael S | 2007/05/13 07:55 AM |
What's your point? | anonymous | 2007/05/13 10:08 AM |
What's your point? | Michael S | 2007/05/13 10:31 AM |
let's stay with x86-64 for now, please | JasonB | 2007/05/13 06:16 AM |
x864 =) (NT) | some1 | 2007/05/15 02:03 AM |
Rock/Tukwila rumors | IntelUser2000 | 2007/05/06 01:27 PM |
Rock/Tukwila rumors | m | 2007/05/13 07:05 AM |
Rock/Tukwila rumors | mas | 2007/05/15 08:40 AM |