-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 11.07.2010 13:26, schrieb Dennis Luxen: >> >> You would you avoid random IO? > > Let me make that more clear. The problem is the number, no the > locations of the I/Os. A good arrangement of the data gives also > good cache-effects.
Ok. I was interpreting it as "ordering the datastructure to faciliate long linear reads over multiple 8k-blocks" instead of the probably intended "ordering it to do reads mostly in 8k-pages already accessed buth with these pages randomly distributed". Let´s stop here until we have actual data-structures to optimize, shall we? I´m quite amazed by the numbers Christian just posted. Do you happen to know the limitations this algorithm has on metrics and the assumptions it makes? How expensive is a partial map-update actually? Does it require a full rebuild of some indice or are incremental updates feasable? >> On a flash-chip random IO is as cheap as linear IO and not much >> slower then RAM access. (both chips being on the same memory-bus >> and no caching or speculative reading in an ARM CPU) > > > Accessing flash linearily gives good cache effects and flash is > certainly not as fast as RAM. I guess you mean from the cached pages because I haven´t read about any speculative read-ahead on any ARM here. Of cause the flash is not as fast as the ram but it´s not the dramatic numbers we know from HDDs. Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw5sGUACgkQf1hPnk3Z0cSWIwCffu9uGtVQgIJ3+K8HQIK+58Fx YvQAnifygqBHoSuuXS1dyKvrvrzJQLPt =NJ2k -----END PGP SIGNATURE----- _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
