Re: [Mono-dev] Use eglib as a default for mono 2.6
On 04/23/09 Miguel de Icaza wrote: The cons are: * We still need to deprecate/break the API for the functions listed in [1] At some point we need to break API/ABI anyway, since it's required for the new GC, we need to hide some implementation details that are currently exposed, like MonoArrayType, MonoMethodSignature, MonoType itself, MonoTypeNameParse, MonoArray and a few ugly API entry points. We need to coordinate to break the API/ABI just once for all the needs, we can't break it 2-3 times. There are still a handful of places where glib is better than eglib, tiny bits here and there, but nothing really major. There are several reasons for having our own code, in no particular order: *) remove a dependency which is getting bigger every day *) being able to inspect inside the data structures (GHashTable for example is opaque and several times I needed to inspect it for debugging; in other cases we'd need to check if the hash distribution is good and we can't with GHashTable) *) GLib doesn't support some APIs we need: a GHashTable foreach that can be early-terminated is one example, we currently waste time visiting it all even if we found what we were looking for. *) we'll never be able to control out of memory cases with glib since it just dies. This can happen in many cases even if plenty of memory is otherwise available for recovery or graceful handling. *) glib installs a compiler-specific file, so the same compiler must be used for mono and glib (this mainly confuses the solaris users, but there are also other cases) *) mono can't be used as a plugin in single-threaded apps that use glib (glib inited without threading support- we die) *) we need about 50 kb of readonly text section to implement the features we need, just linking with glib brings 20 KB of writable memory and several pages of text. *) we really just use a tiny subset of glib the API/ABI break is a good time to switch for the above advantages We could also make sure that the structures map 1 to 1 to the Glib structures for the ones that we use, that would prevent the need to even break the API when using the remapping macros. It doesn't matter, we need to break the API/ABI anyway and such hacks are better avoided. But I can see why this last one might make some people uncomfortable. [1] This is the list of public API entry points that expose Glib data structures. metadata/assembly.h:void mono_assembly_foreach(GFunc func, gpointer user_data); metadata/verify.h:GSList* mono_image_verify_tables (MonoImage *image, int level); metadata/verify.h:GSList* mono_method_verify (MonoMethod *method, int level); metadata/verify.h:voidmono_free_verify_list(GSList *list); [...] There are others, like the ones exposing MonoTypeNameParse, plus all the ones where one is supposed to free results with g_free(). As for the cases where glib might be faster than eglib (small struct allocations, for examples) it's likely that we should optimize mono not do abuse them, because if it's significant in the overall time for mono apps something looks wrong. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
Hello, glib today features a very powerful slab allocator, and this slab allocator does have a performance gain in things like the mcs bootstrap test. I'm not familiar with glib, but is that allocator some rocket science that can't be matched in performance by using some other allocators (dlmalloc, nedmalloc, hoard, ...)? I do not think we need to be rocket scientists, we just need to be good artisans and make sure that we do not regress. Slab allocators typically work by having a stronger relationship between the client and the allocator. Instead of the trivial API Give me N bytes, the API is I will be allocating lots of structures of size X, so these allocators are turned for allocating blocks of a fixed size. This happens for example when allocating lots of nodes for a hashtable, or a linked list for example. This paper describes the original introduction of Slab allocation into the Solaris kernel, where it became popular: http://www.sagecertification.org/publications/library/proceedings/bos94/full_papers/bonwick.ps Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
Hello, Been thinking some more about this: The short answer is: we will never switch to eglib as default. The primary reason is that the eglib symbols would interfere with the real glib symbols used by so many mono apps. What needs to happen is the following: 1) take a data structure implemented in eglib and copy it to mono/utils, renaming the file and the symbols to have mono_ instead of g_ at the start. 2) replace all the uses of that glib data structure in the mono code with the new equivalent mono_ version 3) repeat the above for all the data structures, functions and GLib types used by mono I think that this suggestion is pretty invasive, both in terms of making the internal changes, and to the SVN history, for very little gain. I went and looked at the public API that we expose, and we found that only a handful of glib data types are exposed in our public contract [1]. If we are going to break the API, we might be able to just introduce the new public entry points defined in terms of a new structure but keep all the internals building against eglib with the suggestion that someone had on the list to remap symbol names. This has several benefits: * We can still alternate between glib and eglib. * We can choose to make eglib the default. * We would not clash between eglib and glib. The cons are: * We still need to deprecate/break the API for the functions listed in [1] * We need to continuously monitor the public API to ensure that no new glib structures are ever exposed. This of course assumes that the basic glib data types like gint32 and so on are always compatible between glib and eglib. But this I think is something that we can depend on, since if they were not identical today we would have much worse problems. There are still a handful of places where glib is better than eglib, tiny bits here and there, but nothing really major. We could also make sure that the structures map 1 to 1 to the Glib structures for the ones that we use, that would prevent the need to even break the API when using the remapping macros. But I can see why this last one might make some people uncomfortable. [1] This is the list of public API entry points that expose Glib data structures. metadata/assembly.h:void mono_assembly_foreach(GFunc func, gpointer user_data); metadata/verify.h:GSList* mono_image_verify_tables (MonoImage *image, int level); metadata/verify.h:GSList* mono_method_verify (MonoMethod *method, int level); metadata/verify.h:voidmono_free_verify_list(GSList *list); utils/mono-hash.h:GEqualFunckey_equal_func); utils/mono-hash.h:GEqualFunckey_equal_func, utils/mono-hash.h:MonoGHashGCType type); utils/mono-hash.h:GEqualFunckey_equal_func, utils/mono-hash.h:GDestroyNotify key_destroy_func, utils/mono-hash.h:GDestroyNotify value_destroy_func); utils/mono-hash.h:GHFuncfunc, utils/mono-hash.h:GHRFuncfunc, utils/mono-hash.h:GHRFuncfunc, utils/mono-hash.h: MonoGRemapperFunc func, utils/mono-logger.h:mono_trace (GLogLevelFlags level, MonoTraceMask mask, const char *format, ...); utils/mono-logger.h:mono_tracev (GLogLevelFlags level, MonoTraceMask mask, const char *format, va_list args); utils/mono-logger.h:mono_trace_set_level (GLogLevelFlags level); utils/mono-logger.h:mono_trace_push (GLogLevelFlags level, MonoTraceMask mask); utils/mono-logger.h:mono_trace_is_traced (GLogLevelFlags level, MonoTraceMask mask); utils/mono-logger.h:#ifdef G_HAVE_ISO_VARARGS utils/mono-logger.h:#define mono_trace_error(...) mono_trace(G_LOG_LEVEL_ERROR, \ utils/mono-logger.h: __VA_ARGS__) utils/mono-logger.h:#define mono_trace_warning(...) mono_trace(G_LOG_LEVEL_WARNING, \ utils/mono-logger.h: __VA_ARGS__) utils/mono-logger.h:#define mono_trace_message(...) mono_trace(G_LOG_LEVEL_MESSAGE, \ utils/mono-logger.h: __VA_ARGS__) utils/mono-logger.h:#elif defined(G_HAVE_GNUC_VARARGS) utils/mono-logger.h:#define mono_trace_error(format...) mono_trace(G_LOG_LEVEL_ERROR, \ utils/mono-logger.h:#define mono_trace_warning(format...) mono_trace(G_LOG_LEVEL_WARNING, \ utils/mono-logger.h:#define mono_trace_message(format...) mono_trace(G_LOG_LEVEL_MESSAGE, \ utils/mono-logger.h: mono_tracev(G_LOG_LEVEL_ERROR, mask, format, args); utils/mono-logger.h: mono_tracev(G_LOG_LEVEL_WARNING, mask, format, args); utils/mono-logger.h: mono_tracev(G_LOG_LEVEL_MESSAGE, mask, format, args); After that is done, remove eglib from svn, remove the glib dependency from the mono build, change the libmono version number since the ABI and API breaks, fix all the bugs that showed up because of the changes, make a new release. The library version change will happen together with the other API breaks we have planned (which depend on the new GC and a few other minor changes in the runtime), but that stuff is not required for your needs. So far nobody
Re: [Mono-dev] Use eglib as a default for mono 2.6
Hello, Fair points you make. If we contribute the changes like you suggested, will you make eglib be the default as part of mono 2.6? There is one last bit that we discussed on irc that did not make it to the mailing lists. glib today features a very powerful slab allocator, and this slab allocator does have a performance gain in things like the mcs bootstrap test. I for one do not want to see Mono become slower by making eglib the only option. At least someone needs to do run the various benchmarks on this switch, it should not be hard to do, just build Mono with eglib on x86 and run the usual suspects. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
glib today features a very powerful slab allocator, and this slab allocator does have a performance gain in things like the mcs bootstrap test. I'm not familiar with glib, but is that allocator some rocket science that can't be matched in performance by using some other allocators (dlmalloc, nedmalloc, hoard, ...)? -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
Hi Paolo, Fair points you make. If we contribute the changes like you suggested, will you make eglib be the default as part of mono 2.6? Joachim Ante On 04/15/09 Joachim Ante wrote: Can you guys please switch to eglib as the default across the board, so that this codepath gets properly tested in the real world. We need to move towards using a single mono source base for all our platforms and relying on external dependencies in mono is a lot of pain when we try to build mono. I asked if that could be done for mono 2.4 and it was too late for that, I understand. But could you guys please fix this for mono 2.6. It would really make a big difference for us. I already explained this some time ago, but maybe it was only on irc and at the mono summit. The short answer is: we will never switch to eglib as default. The primary reason is that the eglib symbols would interfere with the real glib symbols used by so many mono apps. What needs to happen is the following: 1) take a data structure implemented in eglib and copy it to mono/ utils, renaming the file and the symbols to have mono_ instead of g_ at the start. 2) replace all the uses of that glib data structure in the mono code with the new equivalent mono_ version 3) repeat the above for all the data structures, functions and GLib types used by mono After that is done, remove eglib from svn, remove the glib dependency from the mono build, change the libmono version number since the ABI and API breaks, fix all the bugs that showed up because of the changes, make a new release. The library version change will happen together with the other API breaks we have planned (which depend on the new GC and a few other minor changes in the runtime), but that stuff is not required for your needs. So far nobody has volunteered for the tasks 1-3. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
Why not take the same route as GNU libiconv? The eglib headers could #define GLib symbols to have a mono_ prefix, distinguishing them from any real GLib symbols that might get linked in somewhere. Mono's runtime code would then not need to be touched and one could still choose to link against original GLib. This approach would work to minimize the amount of work required, but it would still break the public API as the symbols would not be the same and a user mixing both might have interesting compilation/linking issues. Luckily there are not that many public uses of the GLib data types in Mono's public header files, so when we decide to break the API for embedding we can do this at the same time. I personally would like to see also migrate from the glib-provided data types to stdint.h provided datatypes where possible. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
On Thu, 16 Apr 2009 18:53:45 -0400 Miguel de Icaza mig...@novell.com wrote: Luckily there are not that many public uses of the GLib data types in Mono's public header files, so when we decide to break the API for embedding we can do this at the same time. I personally would like to see also migrate from the glib-provided data types to stdint.h provided datatypes where possible. GLib, being a portability library, I think is a nice thing to use. Is there any way that (should the host system not actually have it) the Mono build process could use a local copy of it (or fetch a copy and build it along with Mono) and just use that? That would seem to me a much more reasonable option than leaving altogether. If the host system doesn't have glib, or it has a glib that is far out of date as would seem to be the original cause for this thread, Mono can just build a copy and place it in /usr/local/lib along with its libraries. Just my 2¢, Mike -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [ OK ] signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
GLib, being a portability library, I think is a nice thing to use. Is there any way that (should the host system not actually have it) the Mono build process could use a local copy of it (or fetch a copy and build it along with Mono) and just use that? Yes. That has always been standard practice in all of the Gnome libraries and everything that uses pkg-config. They have always allowed for parallel installation. That would seem to me a much more reasonable option than leaving altogether. If the host system doesn't have glib, or it has a glib that is far out of date as would seem to be the original cause for this thread, Mono can just build a copy and place it in /usr/local/lib along with its libraries. There is no need for Mono to do this. All you need to do is: tar xzvf glib-2.xxx.tar.gz cd glib-2* ./configure --prefix=$HOME/private make make install cd .. tar xzvf mono-2.4.tar.gz cd mono-2.4 export PKG_CONFIG_PATH=$HOME/private/lib/pkgconfig ./configure --prefix=$HOME/private make make install Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Use eglib as a default for mono 2.6
Hi, Can you guys please switch to eglib as the default across the board, so that this codepath gets properly tested in the real world. We need to move towards using a single mono source base for all our platforms and relying on external dependencies in mono is a lot of pain when we try to build mono. I asked if that could be done for mono 2.4 and it was too late for that, I understand. But could you guys please fix this for mono 2.6. It would really make a big difference for us. Joachim Ante ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
Am 15.04.2009 um 16:10 schrieb Paolo Molaro: On 04/15/09 Joachim Ante wrote: Can you guys please switch to eglib as the default across the board, so that this codepath gets properly tested in the real world. We need to move towards using a single mono source base for all our platforms and relying on external dependencies in mono is a lot of pain when we try to build mono. I asked if that could be done for mono 2.4 and it was too late for that, I understand. But could you guys please fix this for mono 2.6. It would really make a big difference for us. I already explained this some time ago, but maybe it was only on irc and at the mono summit. The short answer is: we will never switch to eglib as default. The primary reason is that the eglib symbols would interfere with the real glib symbols used by so many mono apps. Why not take the same route as GNU libiconv? The eglib headers could #define GLib symbols to have a mono_ prefix, distinguishing them from any real GLib symbols that might get linked in somewhere. Mono's runtime code would then not need to be touched and one could still choose to link against original GLib. Andreas What needs to happen is the following: 1) take a data structure implemented in eglib and copy it to mono/ utils, renaming the file and the symbols to have mono_ instead of g_ at the start. 2) replace all the uses of that glib data structure in the mono code with the new equivalent mono_ version 3) repeat the above for all the data structures, functions and GLib types used by mono After that is done, remove eglib from svn, remove the glib dependency from the mono build, change the libmono version number since the ABI and API breaks, fix all the bugs that showed up because of the changes, make a new release. The library version change will happen together with the other API breaks we have planned (which depend on the new GC and a few other minor changes in the runtime), but that stuff is not required for your needs. So far nobody has volunteered for the tasks 1-3. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Use eglib as a default for mono 2.6
On Wed, 2009-04-15 at 22:49 +0200, Andreas Färber wrote: [...] Why not take the same route as GNU libiconv? The eglib headers could #define GLib symbols to have a mono_ prefix, distinguishing them from any real GLib symbols that might get linked in somewhere. Mono's runtime code would then not need to be touched and one could still choose to link against original GLib. Are you volunteering? :-) -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
