Standard accessors

Implementing accessors for scalar attributes in Core Data is somewhat inconvenient, as the framework only generates primitive accessors for scalars, and you’re supposed to write the normal accessors yourself, complete with correct access and change notifications.

The Core Data Programming Guide recommends (in the Scalar Values section) that you implement scalar accessors like this:

@interface MyManagedObject : NSManagedObject {
}
@property (nonatomic, assign) float x;
@property (nonatomic, assign) float primitiveX;
@end

@implementation
@dynamic primitiveX;

- (float)x {
    [self willAccessValueForKey:@"x"];
    float value = self.primitiveX;
    [self didAccessValueForKey:@"x"];
    return value;
}

- (void)setX:(float)value {
    [self willChangeValueForKey:@"x"];
    self.primitiveX = value;
    [self didChangeValueForKey:@"x"];
}
@end

This works correctly, but if you’re using your attributes frequently, you may find that these accessors are surprisingly expensive. For example, I have an application that stores images in a Core Data database. The images consist of sets of bezier curves that are represented by a handful of model classes, each having several scalar attributes for the positions of their bezier control points. To debug performance issues, I wrote a little test case that repeatedly renders a complex image on a Core Graphics bitmap context. I knew that calling all those notifications can’t be very fast, but I was still surprised when I found that when I used accessors that follow the pattern above, those innocent-looking willAccessValueForKey: calls took close to a third of my app’s entire running time, more than all the graphics operations:

Apparently willAccessValueForKey: is somewhat slow because it needs to look up its key parameter in a table, and this lookup isn’t very efficient. (Judging by the topmost method name above, it looks like Core Data may support other (perhaps more efficient) mapping strategies. However, I don’t think there is a way to override the strategy that the framework chooses by default.)

Now obviously my app is somewhat of a pathological case, since (in its current unoptimized state) it enumerates all attributes of all objects multiple times during rendering, resulting in tens of thousands of willAccessValueForKey: calls to draw just a few hundred Bezier paths. But still, it is worth to find out what we can do to eliminate this overhead.

Replace access notifications with explicit fetches

As far as I know, willAccessValueForKey: is only used to fire faults when the object is not yet fully loaded into memory, and didAccessValueForKey: is simply a no-op. Thus, if you can be sure that your objects aren’t faults, then you can safely elide all willAccessValueForKey:/didAccessValueForKey: calls. One way of ensuring that there are no faults is to prefetch all objects before using them. (Prefetching also greatly improves performance when you’re iterating over a large set of items, like my drawing app does. With no prefetching, the profiler results above would have been swamped by Core Data using separate SQLite roundtrips to fetch each individual object.) Unfortunately it’s relatively easy to mistakenly prefetch less than you need, and accessing attribute values without firing the fault will result in bogus values that can be hard to debug.

For a more robust solution than simply removing access notifications, replace them by explicit fault checks. When a fault is discovered, trigger it before touching any attributes. To trigger a fault, simply call willAccessValueForKey: with a nil key. (Note that this only applies to read accessors; write accessors must keep using the original template above. You definitely don’t want to disable change notifications, because KVO and Core Data’s critical change tracking infrastructure rely on them.)

@interface MyManagedObject : NSManagedObject {
}
@property (nonatomic, assign) float x;
@property (nonatomic, assign) float primitiveX;
- (void)fetch;
@end

@implementation
@dynamic primitiveX;

- (void)fetch {
    // Fire the fault.
    [self willAccessValueForKey:nil];
    [self didAccessValueForKey:nil];
}

- (float)x {
    if ([self isFault])
        [self fetch];
    return self.primitiveX;
}

- (void)setX:(float)value {
    [self willChangeValueForKey:@"x"];
    self.primitiveX = value;
    [self didChangeValueForKey:@"x"];
}
@end

Use instance variables

While we are tweaking accessors, it may be worthwhile to represent performance-critical scalar attributes as instance variables, and access them directly whenever possible. To do this, simply declare the backing ivars, and override the primitive accessors so that they get and set attribute values using them. In the normal accessors, you can inline the primitive accessors instead of calling them to shave off a few extra nanoseconds spent in objc_msgsend.

The final code sample below uses ivars and also keeps track of the fault state in a separate boolean instance variable to let the read accessors work without any additional method calls in the usual case.

@interface MyManagedObject : NSManagedObject {
    float _x;
    BOOL _fetched;
}
@property (nonatomic, assign) float x;
@property (nonatomic, assign) float primitiveX;
- (void)fetch;
@end

@implementation
- (void)fetch {
    // Fire the fault.
    [self willAccessValueForKey:nil];
    [self didAccessValueForKey:nil];
    _fetched = YES;
}

- (void)didTurnIntoFault {
    _fetched = NO;
    [super didTurnIntoFault];
}

- (float)primitiveX {
    return _x;
}

- (void)setPrimitiveX:(float)value {
    _x = value;
} 

- (float)x {
    if (!_fetched)
        [self fetch];
    return _x;
}

- (void)setX:(float)value {
    [self willChangeValueForKey:@"x"];
    self.primitiveX = value;
    [self didChangeValueForKey:@"x"];
}
@end

Results

I implemented my Bezier path accessors to follow this last pattern, and additionally I changed my drawing methods to use ivars directly when possible (after a _fetched test) instead of calling accessors at all. At the end, I got this rather healthier looking Time Profiler output:

The app’s running time is now dominated by bounding box calculations (rcu) and drawing operations, as expected. I can push down willAccessValueForKey: even further later by converting a few more attributes.

It is generally a bad idea to ignore the official way of doing things on iOS, but in my particular case the official approach turned out to be so slow that I had to find alternatives. As far as I can see, these hacks will continue to work fine until and unless Apple introduces new Core Data features that rely on access notifications. However, applying them in your project is a still a possible maintenance headache that is not worth risking unless you are 100% certain that standard read accessors have a measurable adverse effect on your overall performance. Don’t waste time and effort optimizing code that isn’t a performance bottleneck, especially not on the advice of random guys on the intertubes! If you do decide to use some of the above tweaks, use Instruments to measure performance before and after implementing all optimizations, and don’t be afraid to roll back your changes when (not if) they turn out to have no measurable effect.

Here is a copy of the problem, in case Encsé decides to delete his post once he finds out it has been tainted with C++ — which would be an entirely sensible (and, indeed, healthy) reaction:

Find a number consisting of 9 digits in which each of the digits from 1 to 9 appears only once. This number must also satisfy these divisibility requirements:

1. The number should be divisible by 9.
2. If the rightmost digit is removed, the remaining number should be divisible by 8.
3. If the rightmost digit of the new number is removed, the remaining number should be divisible by 7.
4. And so on, until there’s only one digit (which will necessarily be divisible by 1).

OK, so I implemented a solution using C++ template metaprogramming. It was actually easier than I thought, and the experience was surprisingly interesting. Which is not to say I’d like to do it again. I imagine I would feel this exact same way after performing an autopsy.

My approach encodes digits as template parameters using variadic templates, which are a recent addition to the language.  They make template metaprogramming more convenient the same way as a drop of mayonnaise would make a shit sandwich easier to swallow.

To make things easier to fit into the template syntax, the digits are encoded “backwards”, with the least significant digit to the left. The interesting part is the search template, which implements a simple exhaustive search (based on lexically incrementing the digit list). It trims the search space whenever a particular (partial) list of digits doesn’t satisfy the constraints above. The solution is not particularly efficient, and since template tail recursion isn’t optimized away, you’ll probably need to increase the maximum depth of template expansion in your compiler. (A limit of 2000 nested templates should be sufficient.) I needed this many levels due to the clumsy recursive chaining that I do in the topmost definition of the search_i template, which is expanded whenever the search tree is trimmed.

// Author: karoly@lorentey.hu, 2010-04-20.
//
// To compile this, you'll need a recent C++ compiler supporting C++0x
// variadic templates.
//
// Sample command line for GCC 4.4:
//
// g++ -Wall -ftemplate-depth-2000 -std=c++0x -o 9digits 9digits.cc

#include <iostream>

// value<DIGITS>::v is the value of DIGITS in decimal.
// The list starts with the least significant digit.
template<int... digits>
struct value;

template<>
struct value<>
{
  static const int v = 0;
};

template<int first, int... rest>
struct value<first, rest...>
{
  static int const v = 10 * value<rest...>::v + first;
};

// contains<ELEM, SET>::v is true if ELEM is in SET.
template<int elem, int... set>
struct contains;

template<int elem>
struct contains<elem>
{
  static const bool v = false;
};

template<int elem, int first, int... rest>
struct contains<elem, first, rest...>
{
  static const bool v = elem == first || contains<elem, rest...>::v;
};

// divisor_test<DIGITS>::v is true if the number of digits
// in DIGITS is a divisor of their decimal value.
template<int... digits>
struct divisor_test;

template<>
struct divisor_test<>
{
  static const bool v = true;
};

template<int first, int... rest>
struct divisor_test<first, rest...>
{
  static const int num = value<first, rest...>::v;

  static const int div = sizeof...(rest) + 1;

  static const int mod = num % div;

  static const bool v = mod == 0;
};

// test_candidate<FIRST, REST>::v is true if cons(FIRST, REST) satisfies
// all constraints, assuming that REST already does.
template<int first, int... rest>
struct test_candidate
{
  static const bool v = (divisor_test<first, rest...>::v
                         && !contains<first, rest...>::v);
};

// search<LENGTH, DIGITS>::v is the first number that is greater or
// equal to the decimal value of DIGITS, satisifies all constraints
// and is of the given LENGTH.  (-1 if there is no such number.)
template<int length, int... digits>
struct search;

template<int length, bool good, bool final, int digit, int... rest>
struct search_i
{
  static const int v = search<length, digit + 1, rest...>::v;
};

template<int length, int digit, int... rest>
struct search_i<length, true, true, digit, rest...>
{
  static const int v = value<digit, rest...>::v;
};

template<int length, int digit, int... rest>
struct search_i<length, true, false, digit, rest...>
{
  static const int v = search<length, 1, digit, rest...>::v;
};

template<int length, int digit, int... rest>
struct search<length, digit, rest...>
{
  static const bool good = test_candidate<digit, rest...>::v;
  static const bool final = good && 1 + sizeof...(rest) == length;
  static const int v = search_i<length, good, final, digit, rest...>::v;
};

template<int length>
struct search<length, 10>
{
  static const int v = -1;
};

template<int length, int next, int... rest>
struct search<length, 10, next, rest...>
{
  static const int v = search<length, next + 1, rest...>::v;
};

template<int length>
struct search<length>
{
  static const int v = search<length, 1>::v;
};

// This program eats cute kittens for breakfast.
int
main ()
{
  std::cout << search<9>::v << '\n';

  return 0;
}

You can download the source and try it yourself if you want. Your doctor would probably suggest that you don’t.

If you step back a few meters and squint your eyes a bit, the general approach may look a bit similar to that of a functional language like Haskell or Clean, except NOT AT ALL, WHAT THE HELL HAVE YOU BEEN SMOKING, STOP COMPARING THIS SENSELESS PERVERSION OF A LANGUAGE TO SOMETHING NAMED AFTER HASKELL CURRY, YOU DERANGED LUNATIC!!!

For shits and giggles I did some compilation benchmarks on my MacBook Pro (2.66 GHz Core 2 Duo, 4 GB). I don’t know how much time GCC version 4.3 needs to compile this… thing, because it still hasn’t finished, but amazingly, GCC 4.4 only required 6.9 seconds and about 115 MB RAM. This actually isn’t too bad at all, especially if you consider some of the alternatives.

Those intertwined template specializations mean that for every list of digits that this algorithm evaluates, it creates a new specialization for the value template, the contains template, the divisor_test template, et cetera, et cetera. To find the value of that single constant expression in the main function, the compiler ends up with thousands upon thousands of these little cross-referencing one-off types. Fortunately, each of them consists of one or more static const members, and none of these structs are ever instantiated, so all traces of them can be completely eliminated from the compiled object file.

All the interesting stuff happens inside the compiler, and the end result is an executable file that is equivalent to the slightly less cuckoo (but unfortunately still C++) program below. GCC 4.4 compiles this trivial program in 0.25 seconds, which is (only!) about thirty times faster than the abomination listed above. GCC is getting pretty good these days, isn’t it?

#include <iostream>

int
main ()
{
  // SPOILERS!
  std::cout << 381654729 << '\n';
  return 0;
}

(Incidentally, a C version that uses printf instead of these mysterious shift operators compiles in under 0.04 secs. I like C. C likes me. You always know where you are with C.)

I could prove that these programs produce the same results by posting the compiler’s assembly outputs, but publishing C++ disassembly is against the Universal Declaration of Human Rights. Compile them and see for yourself, if you dare.

Is this a clever trick? Yeah, it’s undoubtedly pretty clever.

Is this approach useful in real life? Well, there are some considerably less insane use cases. Boost has some well-written examples.

Is it a good idea to use these kinds of language hacks in any project that you or your company depend on? Absolutely not. For example, Boost also includes a rich variety of lovingly hand-crafted C preprocessor hacks. Using C++ template metaprogramming for anything serious is at least as good an idea as using any of those. For best (i.e., worst) effect, try combining the power of templates and the C preprocessor!

Let this post serve as a warning for us all. Please do not use C++ at home. Or at work. Especially not at work.

As far as members of the C language family go, I’m staying with C, Objective C, Java and C#, thank you very much. I hear D is also pretty nice.

Update: GCC 4.3 finished in 15 minutes and 54 seconds, consuming 1.5 GB of address space. Hurray for progress!

Update 2: Cactus has created a Haskell version of this algorithm. Its beauty contrasts nicely with the morbid ugliness of the C++ version.

All this means that in 2010 it may seem a tiny bit too late to publish Palm OS source code. Thankfully the system still has a small group of enthusiastic users who work on keeping the platform alive.  To this very day, I’m still regularly contacted about my old Bluetooth remote control application, which I sadly didn’t keep updated to run on the last few generations of devices.  It’s great that people care about my work, and the least I can do is to let them take control.

So here is a bunch of source code, now relicensed under GPL version 2. I should have done this years ago!

http://code.google.com/p/blue-remote

I find the source to be surprisingly readable, which is a good sign (I haven’t looked at it in years).

For old times’ sake I hope to find some time to install a current Palm OS SDK and work on BlueRemote a bit myself.  In the meantime, please play with it, study it, change it, fix it or pervert it however you fancy. It would be awesome if you contributed your changes back to the “official” project — so by all means contact me if you want to be a project member.

A jelenlegi billentyűzetkiosztás tehát nem jó. Szerencsére érintőképernyős billentyűzetet nem nehéz javítani, csak a szoftvert kell megváltoztatni. De hogy nézne ki az ideális magyar billentyűzet? Sajnos a képernyő viszonylag kis mérete miatt nem volna járható út mind a kilenc ékezetes betűnek saját gombot adni: ehhez túlzottan össze kellene nyomni a gombok méretét, és az apró billentyűket talán még a jelenlegi megoldásnál is frusztrálóbb volna használni.

Ha kirándulunk egyet a telefon beállításai között, és bekapcsoljuk a cseh kiosztást, egy zseniális megoldásra lelhetünk:

A második és harmadik sor egy-egy extra billentyűje segítségével építhetjük fel a cseh ékezetes betűket. Amikor megnyomjuk őket, az előttük álló alapbetű tetejére egy vessző ill. egy hacsek kerül, így észvesztően könnyen és gyorsan tudunk gépelni. Az így felépített ékezeteket az alapbetűtől függetlenül lehet törölni, így a véletlenül hibásan bevitt ékezeteket is nagyon egyszerű kijavítani.

A magyar változathoz nem kettő, hanem három extra billentyűre volna szükség, de egy kis turkálással találhatunk ilyen kiosztásra is példát. Íme a dán billentyűzet:

Ezen kiosztáson a gombok egy kicsit keskenyebbek, mert felső sorban helyet kellett csinálni az Å betűnek.  Szerencsére ez nem rontja jelentősen a gépelés élményét (pláne nem fektetett üzemmódban), úgyhogy az extra gombokat cseh kiosztáshoz hasonlóan működő ékezetekre cserélve remek magyar billentyűzetet kapnánk:

Már csak az a kérdés, hogyan változtathatjuk meg a telefon kiosztását. Az App Store sajnos nem támogatja új billentyűzetkiosztások rendszerszintű telepítését, de az Apple a tapasztalatok szerint meggyőzhető arról, hogy érdemes fejleszteni, ha elegendő számú megfontolt és udvarias hangvételű felhasználói visszajelzést kap. Úgyhogy bátran ragadjunk tollat, és töltsük ki a megfelelő űrlapot (lehetőleg angolul)! A 4.0-ás iPhone OS-be már nem férne bele egy ilyen módosítás, de a 4.1-be biztosan.

Az igazi, hardveres billentyűzettel rendelkező telefonokon nem volt költséghatékony csak a magyar piac kedvéért extra gombokat tenni, de szerencsére érintőképernyőkön már ennek semmi akadálya nincs. Fogjunk össze, és tegyük ezt a kiosztást szabványossá az érintőképernyős telefonokban!

Update: A fejlesztő kollégák a 8134383-as bug reportot is megdupe-olhatják a radaron.

My original implementation on ancient Palm PDAs/smartphones emulated a standard Bluetooth peripheral and it did not need special software running on the computer — similar apps on the iPhone work over WiFi and require starting up special server programs.  This is to be expected, since Palm supported third-party applications accessing the Bluetooth radio (they even provided a reasonably convenient & full-featured API for it), while Apple does not.  This is, at the end, a good thing: there is a limit to what an Apple-blessed app can do to an iPhone.  Buggy Palm applications could and did frequently crash the device.  There was a proliferation of third-party hacks that hooked into system internals and changed essential system behaviour, invariably destabilizing it.  The Treo was a great toy, but a horrible phone — I had to reset it multiple times per day and learned not to rely on it for anything important.  I can’t even remember when I last rebooted my iPhone.

The royalty checks I received for BlueRemote over all these years have paid back the price of the development kit (i.e., my Tungsten T2 and Treo 650), with perhaps just a little extra.  I believe this was considered a success back then, considering that I did not do any marketing whatsoever.   BlueRemote’s price was $14, with (AFAICR) 60% going to Motricity’s pockets.  For contrast, the going price for similar software in the App Store is 1$, with 70% going to the developer.  (The Logitech app is for promoting their hardware, so it’s free.)  The fact that it still seems worthwhile for one-man teams to produce software for 0.7$ a pop is a testament to the App Store’s success.

Once in a while, I still get an email complaining that BlueRemote does not work on the lastest generation of Palm OS devices, with their fancy new Bluetooth chips. It would be mildly amusing to fix this at some point and release an update.

Ugyanez hónapokra lebontva:

Végezetül itt egy montázs a legtöbbet hallgatott előadóimmal 2004 és 2010 között: (eredetileg ez egy szép, klikkelhető image map volt, de a szuper-duper wordpress.com-nak kiütése lesz az ilyen modern HTML fogásoktól.)

Hát nem lebilincselő diagramok?   Jól látható, hogy szeretem, ha őszülő, hosszú hajú férfiak duruzsolnak a fülembe!  (Mellesleg fogalmam sem volt, hogy olyan sok Stephen Lynchet hallgatok, hogy már a top 20-be is bekerült — megyek, le is törlöm a telefonomról.)

A lejátszások számára alapuló statisztikák egyébként egy kicsit félrevezetőek, mert már évek óta sokkal több időt töltök podcastek hallgatásával, mint zenével.

Egyik magyar pártra sem lehet jó szívvel szavazni.  Nincs legkisebb rossz.  És az a leginkább borzasztó, hogy a kampány csak most kezdődik: ennél már csak lejjebb süllyedhetnek.

Amiért meg sem fordul a fejemben, hogy a Fideszre szavazzak

Amiért meg sem fordul a fejemben, hogy az MSZP-re szavazzak

Amiért meg sem fordul a fejemben, hogy a Jobbikra szavazzak

Amiért meg sem fordul a fejemben, hogy az MDF-re szavazzak

Amiért meg sem fordul a fejemben, hogy a KDNP-re szavazzak

Amiért meg sem fordul a fejemben, hogy az LMP-re szavazzak

Amiért meg sem fordul a fejemben, hogy az MKMP-re szavazzak

Amiért meg sem fordul a fejemben, hogy a Zöld Pártra szavazzak

Kihagytam valakit?  Párthívek ellenvéleménye?

Egyelőre úgy fest, a Lemon Party vagy az MKKP fog ikszet kapni tőlem.

Bizonyára Önnel is számtalanszor előfordult már, hogy egy mindig a Föld középpontja felé forduló, fekete ködbe vesző, artériás vér színű harmadfokú Menger spongya-közelítést szeretett volna megfigyelni, de épp egyetlen ilyen sem volt a közelben. A Menger App segítségével ezentúl bármikor kielégítheti ezirányú vágyait!

A Menger App az iTunes App Store-ban nem hozzáférhető, csak elit kiválasztottak egy szűk köre juthat hozzá. Kápráztassa el barátait!  Menger App!

Igazából persze csak a móricka 3D motorom kipróbálásához kellett valami bonyolultabb tesztmodell, amihez kapóra jött, hogy mindenki Menger-lázban ég körülöttem. Nosza kitaláltam hogyan lehet leírni a szivacs felületét adó poligonokat, és a kapott rekurzív algoritmust egy borzasztó ronda Python szkripttel jól meg is implementáltam. A módszer érdekessége, hogy a triviális, kockákból építkező megoldással ellentétben csak a szivacs tényleges felületét generálja, a belső, láthatatlan lapokat kihagyja. További érdekesség, hogy a szivacs közelítéseinek felszínén lépten-nyomon megfigyelhető, nyolc négyzetből is kirakható „lyukas négyzet” formát a program az alábbi nyolc, láncba fűzhető háromszöggel írja le, ezzel is csökkentve a kimenet méretét:

Ezzel együtt is például a fenti harmadfokú közelítés eredménye 46 848 csúcspontból áll, amik 27 648 háromszöget feszítenek ki. (A negyedfokú változat ugyanezzel a módszerrel 912 384 csúcsból és 528 384 háromszögből állna.) Sok persze a duplikált csúcs, és nagyon-nagyon megérné egy utófeldolgozási menetben hosszabb háromszögláncokat is keresni, de a célnak a modell így is megfelel.

Az alkalmazás az előzőleg legenerált kész modellfájlt egyszerűen be-mmapolja a címterébe, aztán a kapott blokkot simán vertex arrayként használja.

Mint kiderült, ez a kevesebb, mint 30 000 háromszög pont elég ahhoz, hogy 13-15 fps mellett 100%-ra kihajtsa az iPhone 3G grafikus gyorsító csipjének transzformáló egységét, miközben a processzor terhelése 50% alatt marad. A verem-minták szerint VBO-k használata esetén is a CPU javarészben folyamatosan vektoradatokkal eteti a segédprocesszort, tehát a VBO-k az iPhone-on nem érnek kutyafülét sem. Ez mondjuk egy dedikált grafikus memória nélküli gépen nem is annyira meglepő.

Ráadásul a szivacsmodellben pillanatnyilag minden csúcs mellett egy normálvektort is transzformálni kell, tehát a GPU majdnem dupla annyi melót végez, mintha csak a csúcsokat számolná. Ezt persze teljesen feleslegesen teszi, hiszen a spongyában csak hatféle normálvektor van, és ezek közül egyszerre csak legfeljebb öt ad a képernyőn is nyomot hagyó háromszöget.  A screenshoton pl. csak háromféle irányultságú háromszög látható, a többi a kamerától elfelé néz. Ezeket helyből ki lehetne zárni a megjelenítésből, kár is őket elküldeni az MBX-nek.

Ha a háromszögláncok maximalizálása mellett a normálvektorokat sem csúcsonként adnám meg, hanem irányultságonként különválogatnám a pontokat, szerintem simán meglehetne a stabil 25-30 fps – de ez egyelőre maradjon házi feladat.

A sebességtesztek szerint az iPhone 3G végsebességben olyan 680 000 háromszöget képes feldolgozni másodpercenként. Ehhez képest az én 15 * 27 648 = 414 720 eredményem lópikula, de ez a fenti optimalizálási lehetőségek alapján nem olyan meglepő.  Az viszont nagyon meglepett, hogy az elvileg sokszorta gyorsabb 3GS modellen a változatlan tesztprogramom még a 3G-nél is 1-2 fps-sel lassabban fut!  Na ezt magyarázza meg nekem valaki.

Oktogon, Budapest