News for Friday, 20 May 2005

Here's Patrick talking

Hello,
for promoting our reseller activity, we thought we could offer a free Internet access in the bar of Carcassonne circuit (Aude, France). A simple aquarium would do..:)
A mini with a FreeBox [modem], Tiger and Safari in Kiosk mode (Saft) will do
All the visitors (mainly Windows users) are astonished.
An idea to develop...?

Of course, the aquarium doesn't have any water inside :)

We asked guiguiguillaume, member of our forums, to provide us with some information and reflexions about Dashboard. Here's his first draw, that shall probably be completed later on.

After your message, I went further into my researches on the issue of memory used by widgets. It's essentially questions I had about widgets, yet some researches made some other things appear.
About Dashboard being slow...
First of all, what I'm pointing here is not that the translator is slow (probably more because of the systran than the host machine), but that launching Dashboard is slow.
Basically I'm not the activity monitor fan, I mean, either my machine lags or not, whatever the figures...
In the present case, my personal selection of 8 widgets is often slow (on my G4 1.25, 512/80@4700tpm), that's why I went looking for what interesting things the figures had to say.
Not a big guess that the swap is responsible of the widgets slow appearance, and moreover, the slow mouse focus on them for interacting. A second consecutive launch of Dashboard will be immediate, while during the first one, the HDD would work until the system will let you grab hold at 100 % again.
Not very surprising when you see what RAM amount the widgets will request. Over time some will use 15 Mo... 8 times, you imagine what that makes. About it:
- I didn't quite get why the situation got worse over time, yet that's the case. The weather widget will use 5 Mo on launch, and will use 20 after 3 days...
- a portion of this RAM undoubtedly is shared (you can't just add rough values), thus artificially increasing the total amount, yet in what proportion it is hard to tell.
I first thought it was to much, and wondered if there weren't any grievous architecture misshapings. My first idea was that each Widget could duplicate some WebKit code in its RAM space... but this didn't make much sense (what's the point in having a "library" if you duplicate your code), and this just doesn't seem like it can be done.
I renounced the idea of a link between swap time and the power and speed of the WebKit, experimentaly. If it was rendering that took such machine time, it would have been possible to get more performance by making sure the different parts of the WebKit really were in RAM (not in SWAP), and that is easy to do, you just have to have Safari display some pages (I took care to get pages with some JS, png, gif... to be sure) before launching Dashboard. It won't seem to have much impact on Dashboard launching performances.
One step further was to monitor closely the request to virtual memory, more specifically OSX, to find out when it would go and seek memory parts in virtual RAM to put them in physical RAM. At least, I get a good measure of what RAM amount transits.
As expected, a direct call to Dashboard, if it was just launched, won't cause any pagein.
On the other hand, when saturating my physical RAM physique (by launching Garageband, 10 tracks; mail, adium, safari, iPhoto, GoLive, Word...) and call Dashboard again, I measured 6,000 to 8,000 page-ins with my 8 widgets. Without any widget, calling Dashboard alone would cause 100 to 200 page-ins ; Dashboard with the clock widget only about 500 pageins.
To compare, with a similarly saturated system, putting iPhoto to the forefront (edition of a picture mode) will cause about 2,800-3,000 page-ins.
Though those are fairly precise measures, you realise a loaded Dashboard will necessitate twice as much memory access than displaying an edition mode of iPhoto, which accounts for its slowliness.
You might explain dashboard slowliness by looking to its architecture as Apple described it: for stability reasons, the widgets are independent processes(you may cause a widget to fail, withtout the wholde widget collections to stall), each one related to its webkit for dispaly and JS interpretation purposes, but also more intricately related to the system (possibility to call the system, Obj-C particularly, via JS). Which can be even harder as the code can't be entirely compiled in the Widget, which will let the "runtime" some more job to do ("finishing the compilation" during execution).
To make Dashboard stable (RAM protection for the widgets) and allow easy programming (yet potentially as powerful as programming in Obj-C native), you have an architecture that gives each widget a consequent weight, in an independent process.
That's why launching Dashboard takes so long. It's the typical "10 small things will result in one huge" thing. Especially as those "small things" are called for simultaneously, thus resulting in much competition in the call of the system.
Can Apple increase performances? One can imagine they already thought of putting the Dashboard drawing in cache to allow a quick rendering of the "superposed" Finder, and from the architectural point of view (for what I could see), the choices made were quite good; even if one theoretically speculate on other execution modes (less protected), that would compile (on launch or installation) the active widget codes in a single execution context... well... at this level many hypotheses are possible.
The main problem in my view lies in RAM restitution of the n execution contexts for n proceses for their update on launching Dashboard.
And there there's no miracle, if those n processes are in swap, with so much competition, with a saturated system (physically recalling a page will put another in swap), it's long. Not often more than 10 seconds to get back 100% control, but it's like eternity...
More RAM to avoid that Dashboard is put in swap is still the best way to do. You might also recall Dashboard 3 times a minute to make sure it won't go in swap, yet this will be kind of annoying.

In the current war for defining the future DVD format, news keep spreading. TDK has developed a 4-layers Blu-Ray media featuring 25GB storage capacity per layer, so a total of 100GB for a 12cm disc. Not bad.
But now TDK has to convince the Blu-Ray alliance that this media could be the default media for the not yet announced future DVD format...
One remaining question: the price. What will be the price of such 4-layer Blu-Ray media?? When one can see the current price of a dual layer DVD media and the total commercial flop of such media, manufacturers will have to prepare a competitive pricing strategy facing competition with other storage system such as HD.

the PC graphic card manufacturer, sapphire, will release in a near future a model based on a Radeon X850 cooled with a liquid metal-based system.

In this system, the cooling liquid is a gallium-based metal which flows through the pipes thanks to a totally silent electromagnetic pump. But the size of the exchanger is not large enough to totally eliminate fans.
If it proves to be efficient and a valuable alternative, we could see this system applied to other "warmed" components.

If you visit the BMW website, you will realize that iPod has gone beyond its classification as peripherals... "discover the ultimate accessory for your iPod"

such commercial ad and statement originating from such a prestigious company : what a honor for Apple.

The Firewire 800 norm is now over two years old. Yet it seems to be going nowhere, partially because Apple doesn't implement it on the consumer Macs, saving it for PowerMacs and Powerbooks. The resulting market being very limited, manufacturers didn't invest in it.
For instance, it is still impossible to find a Firewire 800 hub! (see update below).
Intel could be the saviour of 1394b because it will be implemented on the D955XBK high end chipsets.
The number of potentially compatible machines will therefore explode, and that should help the number of Firewire 800 peripherals to soar.
[update] It seems a few FW800 hubs do indeed exist, but they are very expensive, which explains their confidential distribution.