Spin is spin, but...

Spin is spin, but...

Posted Oct 19, 2008 15:04 UTC (Sun) by khim (subscriber, #9252)
In reply to: Back to Adobe's excuse making by tialaramex
Parent article: Linux now an equal Flash player (Linux-Watch)

Adobe used to tell Photoshop users they didn't want unlimited Undo History, it was a crutch for people who didn't use their image editing software the right way, and then one day Photoshop implemented it and suddenly Adobe couldn't say enough about how great it was.

If that's really the most they can offer to 64bit users then previous position was correct: 64bit version offer only tiny improvements, not something truly spectacular.

You're mistaken about PC video games, it's nothing to do with 3D or Windows. It's all about DOS extenders. The DOS extender was supplied with your tool chain, effectively part of the run time. Despite DOS being 16-bit the "extender" would push the CPU into 32-bit flat mode, so all your actual development would be in 32-bit. DOS extenders were fairly rare when Doom had one, but by the time Quake arrived in 1996 everything in the PC section of your games store would be 32-bit code run by a DOS extender. Even simple point-and-click adventure games, which could have been coded for 16-bit DOS with overlays or similar tricks weren't bothering, 32-bit development meant less headaches for developers, which meant shorter time to market.

A lot of games were 16bit back then. I still remember that Larry7 (1996) and Enemy Nations (1997) worked fine with Windows 3.1 (I had no hardware for Windows95 back then) and thus were quite happy with 16-bit system. Only by the 1997 games started dropping 16bit mode support (and Quake was released June 22, 1996, don't forget).

I'm not really sure what to make of your claims about DOM and so on. If web browsers actually need billions of DOM objects, URIs, images etc. then isn't it a surprise that they've ever worked on 32-bit machines?

I wanted to say that browsers work with a lot of small objects and so it makes perfect sense to use 32bit mode. Only if/when web pages will start to include billions of said objects 64bit mode will make sense. Basically either they work with small pages of today (and then 32bit mode is the best choice) or they handle ubercomplex pages of tomorrow (and then all these schemes with indexes are useless). Transition phase is short - and it's some years in the future...

Or on the other hand, if as seems more likely they have a few million DOM objects, a few million URIs, and a few thousand images, then 32-bit handles are fine, and will be long after 32-bit memory isn't nearly enough.

Actually this time is short. Memory requirements double every year and half on average. That means if you have one pointer per ten words or useful data (not uncommon for many different types of applications) then time where your "32bit indexes but 64bit pointers" scheme works is five or six years! And it's just stupid to write program which can only be useful for five years - much better to just refuse to switch to 64bit till your data and indexes work in 32bit mode (that's fastest mode) - and then switch to 64mode. With some tricks (move images and video handling to separate process, etc) you can manage to work with 16GiB of RAM (may be even 32GiB or RAM) while in 32bit mode and then this "window of opportunity" shrinks even further (this tricks will slow down your program, of course, so at some point 64bit mode will be just faster with no strings attached - and THAT is the time when you need to switch).

/Choosing/ to use pointers everywhere you can is a design decision, and not automatically a good one.

Sorry, but I don't buy it. Indexes are kludges: at some point you'll have so many objects in your program that 32bit indexes will just not work (Windows 98/ME was hit by this problem pretty hard: GDI objects used indexes is 16bit tables and so it was not uncommon so see system with many mibirytes of RAM crash or behave erratically because it had no room to create yet another window or yet another brush). Wrappers around pread() and pwrite() are kludges too. But there are a difference: wrappers around pread() and pwrite() allow you to use old libraries and programs for a while in the "brave new word or multigibibyte RAM" while indexes make life easier for a while but then require redesign of the whole system (something like Windows 9X => Windows XP transition). Thus IMNSHO indexes are more evil then wrappers.

Negative effects from increased native word size need to be characterised in terms of what users would actually notice. If the user won't notice, we shouldn't care.

Sorry, but it's the other way around: positive effects must be measured and if the user won't notice there are no need to switch to 64bit yet. Why? Easy: we already have working 32bit stuff and 64bit stuff must prove itself before it'll be accepted. XP 64bit was total flop and Vista 64bit is not so hot either - and that's prerequisites! While there are no 64bit OS there are no 64bit programs... You need at least ONE program which shows that 64bit OS is worthwhile and even after that switch from 32bit to 64bit will be on case-by-case basis...

That actually the policy around here: if application can work in 32bit mode - it must be used in 32bit mode in production (most our programs are memory-bound, not CPU-bound), but all tests must pass in 64bit mode too because switch is unavoidable. At some point.

---

(Log in to post comments)