Bugzilla – Bug 319132
[GMCS] Performance regression
Last modified: 2007-09-15 21:24:46 UTC
---- Reported by nazgul@omega.pl 2005-09-28 14:01:40 MST ---- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: class Continuation<R,A> { public static Continuation<R,A> CallCC <B>(object f) { return null; } } class Driver{ static Continuation <B,A> myTry<A,B> (object f, A x) { return Continuation<B,A>.CallCC <object>(null); } public static void Main() { myTry <int, int>(null, 7); } } Actual Results: with mono 1.1.9 ** ERROR **: file metadata.c: line 1810 (mono_metadata_parse_generic_param): assertion failed: (generic_context with mono svn ** ERROR **: file metadata.c: line 1879 (mono_metadata_parse_generic_param): assertion failed: (index < generic_container->type_argc) Expected Results: clear run How often does this happen? always Additional Information: One of Martin's latest changes caused Nemerle compiler to stop working with the same assertion (index < generic_container->type_argc). I guess it might be related. ---- Additional Comments From martin@ximian.com 2005-09-28 15:12:34 MST ---- Created an attachment (id=168587) Quickfix ---- Additional Comments From martin@ximian.com 2005-09-28 15:15:07 MST ---- Attached is a quickfix for the problem - it passes all the generics tests. I'm currently redesigning method_from_methodspec() to make it cleaner and easier to understand. ---- Additional Comments From martin@ximian.com 2005-09-28 15:33:10 MST ---- Committed the patch and added gtest-206.cs. Is Nemerle still broken after r50965 ? ---- Additional Comments From nazgul@omega.pl 2005-09-28 15:40:39 MST ---- Yes, there are still some issues (the same assertion fails). I guess I will wait till you finish the refactoring to check and maybe report a new example. Alternatively you can svn co http://nemerle.org:81/svn/nemerle/trunk nemerle cd nemerle ./configure --mono-from=/path/to/mono/bin/ it fails immediately during configure when trying to test-compile the simplest program. ---- Additional Comments From martin@ximian.com 2005-09-28 20:43:03 MST ---- Hey, that's exactly what I was looking for :-) Adding some large consumer of generics to the set of tests I'm always running on my machine before committing such changes. Our current gtest-*.cs test suite is good, but far from complete - so in the past it was always very difficult to make changes to the generics code without knowing whether I broke something or not. After several hours of debugging, I'm almost done with a fix which'll pass a full Nemerle bootstrap in addition to the full mono bootstrap :-) ---- Additional Comments From martin@ximian.com 2005-09-28 21:10:31 MST ---- Ok, just committed a patch which should fix this. Nemerle's ./configure works, but if I do a `make', it seems to be hanging: === martin@rohan:/work/gondor/nemerle> ./configure --prefix=/work/gondor/INSTALL --mono-from=/work/gondor/INSTALL/bin Checking for .NET environment... /work/gondor/INSTALL/bin/mono Checking if we are using Mono < 1.1.9... no Checking for presence of regtool in the system... not found Checking for .NET disassembler... /work/gondor/INSTALL/bin/monodis Checking for native image generator... disabled Checking if Nemerle compiler works... yes Checking for gacutil... found Checking if we are using mono gacutil... yes Checking for mono libdir... /work/gondor/INSTALL/lib Checking for PEVerify... not found Checking for ilasm... found Checking for C# compiler... found Checking for Python version... 2.3, ok Checking for antlr >= 2.7.5... not supported Checking for nant... no Checking for nunit-console for .NET 2.0... not found, some tests will be disabled Creating config.mak Creating nemerle.pc martin@rohan:/work/gondor/nemerle> make make[1]: Entering directory `/work/gondor/nemerle/ncc' make[2]: Entering directory `/work/gondor/nemerle/ncc' MKDIR out.stage1 make[3]: Entering directory `/work/gondor/nemerle/ncc' COMPILE [stage1] Nemerle.dll ____________________________________________________________ ------------- STATS --------------- AllTypeBuilders: 170 FirstClassFunctions: 24 RealRunningTime: 9989ms ------------- END STATS --------------- COMPILE [stage1] Nemerle.Compiler.dll ________________________.................................... typing/Macros.n:421:9:421:21: warning: this match clause is unused ____________________________________________________________ ------------- STATS --------------- AllTypeBuilders: 1219 FirstClassFunctions: 452 RealRunningTime: 97440ms ------------- END STATS --------------- COMPILE [stage1] Nemerle.Macros.dll ____________________________________________________________ ------------- STATS --------------- AllTypeBuilders: 303 FirstClassFunctions: 157 RealRunningTime: 34635ms ------------- END STATS --------------- COMPILE [stage1] ncc.exe ____________________________________________________________ ------------- STATS --------------- AllTypeBuilders: 5 FirstClassFunctions: 3 RealRunningTime: 7166ms ------------- END STATS --------------- make[3]: Leaving directory `/work/gondor/nemerle/ncc' make[2]: Leaving directory `/work/gondor/nemerle/ncc' make[2]: Entering directory `/work/gondor/nemerle/ncc' MKDIR out.stage2 make[3]: Entering directory `/work/gondor/nemerle/ncc' make[3]: Circular out.stage1/ncc.exe <- out.stage1/ncc.exe dependency dropped. make[3]: Circular out.stage1/Nemerle.Macros.dll <- out.stage1/ncc.exe dependency dropped. make[3]: Circular out.stage1/Nemerle.Macros.dll <- out.stage1/Nemerle.Macros.dll dependency dropped. COMPILE [stage2] Nemerle.dll ____________________________________________________________ ------------- STATS --------------- AllTypeBuilders: 170 FirstClassFunctions: 24 FunctionClosures: 25 RealRunningTime: 134125ms ------------- END STATS --------------- COMPILE [stage2] Nemerle.Compiler.dll __________.................................................. ====== I killed the process after running for about 20 minutes. When attached to it in gdb, I realized that it seems to be JITing the same method `Nemerle.Collections.Tree._N_insert8351' over and over again. Is that normal ? Hmm, that's a generic method and it's always JITed with a different instantiation. Maybe we really need shared code. ---- Additional Comments From martin@ximian.com 2005-09-29 09:29:16 MST ---- Ok, I started another Nemerle bootstrap before I left to my lunch break and now it's finished after about an hour :-) ---- Additional Comments From nazgul@omega.pl 2005-09-29 13:00:04 MST ---- Actually it is some performance degradation, which must have appeared within your recent changes... Probably some caching of instanciated signatures ceased to work (as I remember the similar thing was happening when Michal was fixing performance issues some months ago - https://bugzilla.novell.com/show_bug.cgi?id=MONO75444). The preformance degradation is about 15x slowdown. What is very strange and interesting is that there is some slowdown at stage1 (compiler compiled using MS bootstrap from nemerle/boot/), but the one in stage2 is 8x worse... Looks like the bug https://bugzilla.novell.com/show_bug.cgi?id=MONO75974 causing duplicate methodref is making things worse. You can easily compare with mono 1.1.9, where performance is ok. ---- Additional Comments From martin@ximian.com 2005-09-29 13:23:10 MST ---- Ok, I'll have at this duplicate MemberRef problem tomorrow. ---- Additional Comments From nazgul@omega.pl 2005-09-29 13:30:09 MST ---- Well, some time ago we were curious if you'd accept such a big... testcase :D I think that after generics code gets stabilized again it would be a great idea to have Nemerle bootstrap at hand to test the changes. As we can see, it would be especially useful in tracking performance regressions. We are looking forward for implementation of code sharing, but it seems that this is not a highest priority issue - the performance on MS.NET is not very different currently than on mono, but this might just mean that their implementation is broken somewhere. And thanks very much for your work on all this stuff! :-) ---- Additional Comments From malekith@pld-linux.org 2005-10-02 11:43:53 MST ---- This patch: http://lists.ximian.com/pipermail/mono-patches/2005-September/064859.html is what is killing the performance. Investigating. ---- Additional Comments From martin@ximian.com 2005-10-04 04:02:59 MST ---- Ok, I'm now looking at it. ---- Additional Comments From martin@ximian.com 2005-10-04 06:24:03 MST ---- Fixed in SVN. The Nemerle bootstrap now takes 2:47 minutes for me :-) Imported an attachment (id=168587) Unknown operating system unknown. Setting to default OS "Other".