Re: [Mono-dev] Mono-devel-list Digest, Vol 96, Issue 26
XWT maybe? Don't know though whether it's mature enough. On śro, 2013-04-24 at 13:09 +0100, Rauf Butt wrote: Hi Alexandre, WinForms is specific to Microsoft platform. Additionally, it will require license too. The purpose of using GTK or Mono is specifically because of the cross platform compatibility. Regards, Rauf Date: Wed, 24 Apr 2013 11:00:28 +0600 From: ? alexandre.shevche...@gmail.com To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] GSoC 2013 MonoDoc Editor Hi all. I am third year undergraduate from Perm State University, Russia and I have a question about MonoDoc Editor project. Is it necessary to use only proposed GUI toolkits for interface implementation? I mean GTK# for Windows and Linux. What about Winforms? Yes, GTK# is faster, but I think speed is not critical in this project. It is unlikely to be a complex and heavy interface. Regards Aleksandr Shevchenko. ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Few notes about finalization
On śro, 2012-12-05 at 13:56 +0100, Konrad M. Kruczynski wrote: Hi all, it is rather known fact that adding a finalizer to the class can hurt performance quite badly with generational garbage collectors. This is due to the premortem finalization used by CLR. If an object is not reachable during GC, but has a finalizer, it will survive and probably be promoted to the next generation. Not so bad in its essence, but such object will transitively make all referenced objects alive and these will be promoted as well. Consider simple benchmark contained in the attached file Test705.cs. The intstances of classes are being born and dying, also they have reference to the table of objects. The class A has an finalizer. On my computer (SGEN, Mono 2.10.8) the result is: Took 00:00:32.4182579 If you comment out the finalizer, the result is: Took 00:00:04.2515352 So the difference is significant. Most of the time (at least from my experience) developers do not need premortem finalization. That is, they do not need to have the reference to the instance that is being finalized. What they need is some kind of simple callback called after this instance is GCd (the callback could also have some kind of parameter related to such instance). As you can see, this is also the case in the mentioned example -- the reference to the original instance is not needed. When I encountered internal sgen API for reference queues, I thought that this could be used to do postmortem finalization. Unfortunately, the API was not stable yet and therefore not public. But there is another, very simple idea. Instead of having a finalizer in A, one could do dummy class B (with its own finalizer) to instance of which A would have a reference. Therefore B's finalizer would serve as a callback function of A. The attached example Test706.cs is based on this idea. And the result is: Took 00:00:04.6424758 So it is in the same order of magnitude. Yup, this is very simple idea, nonetheless works well and did not come to me as a solution immediately, so maybe this will be useful to someone. Or I am wrong somewhere ;) -- It may be worth adding, that with the fresh Mono from GIT the results are similar (although new sgen is faster in general which is a good news), respectively: Took 00:00:28.1762050 Took 00:00:03.5601241 Took 00:00:03.9642138 -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Inspecting x86 assembly
Hi again, forgot to cc previous mail to the list and maybe someone will find it useful too. mono -v -v can be used to obtain assembly. Btw, AOT output can not necessarily be the same. On Fri, 2012-11-16 at 21:37 +1100, Daniel Lo Nigro wrote: You can use Ahead of Time compilation to generate a .so file with native code. Is this what you're looking for? http://www.mono-project.com/AOT On Fri, Nov 16, 2012 at 7:15 PM, Stack Pointer stackpoin...@me.com wrote: I want to inspect the x86 assembly that mono generates from my .exe. Mostly for specific functions. How do I achieve this? $ mono --help-devel tells me that I could compile a method and generate assembly for it. How should I be using it? If I do: $ mono --ncompile 1 --compile METHODNAME EXENAME EXEOPTIONS I get an error saying: Usage: mini --ncompile num --compile method assembly How do you guys inspect the generated assembly while developing? Is there some other internal option that enables that? Thanks, Vrajesh ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] To say hello and ask some questions about Mono...
Hi, do not hesitate to contact me if you like, but the idea seems rather vague to me. Mono development is currently lead by Xamarin which is also open to accept ideas and patches from community. How this really works, you can observe at github: https://github.com/mono/mono.git The amount of community driven patches probably increased with git and github as it simplifies submitting and merging patches. On the Microsoft side, the actions that helped Mono development were open sourcing some parts of .NET (for example DLR, lately Entity Framework) using useful licence (Apache 2.0, for that matter). One could probably create wishlist containing another parts. For example Nuget, which theoretically admits Mono existence, but support is severely limited (for example try to create package). But the most important question here is: what is the role of the foundation here? On Sat, 2012-09-29 at 20:37 +0200, Leszek Ciesielski wrote: There's quite a few Mono contributors coming from Poland, starting with Xamarin's Marek Habersack. Other active community members include Marek Sieradzki and Konrad Kruczyński. Perhaps it would be best for you to reach out to those people personally? On Sat, Sep 29, 2012 at 5:45 PM, Robert Wilkens robwilk...@gmail.com wrote: I'm not an expert (in complete honesty), but i think microsoft is free to contribute to mono's development as long as they contribute it under i believe it is the mit/x11 license, which may or may not be desirable to them. I also have heard that as far as moonlight goes, the silverlight equivalent for linux like platforms which i think is based on mono, I am pretty sure i heard microsoft did make a contribution as far as providing unit tests or something to that extent. -Rob On Sep 29, 2012, at 11:27 AM, Michał Smereczyński mic...@aegis.org.pl wrote: Hello there, My name is Michael Smereczynski. I'm vice-chairman of Aegis - Polish open source software foundation (we pretend to be like Apache Software Foundation but now we are doing our job only in Poland). Personally, I'm not a programmer (but I allways wanted to do something by myself - maybe in future). So if I'll ask You something stupid, please don't hurt me ;) I am a man who comes from the assumption that the Linux users do not need to be evangelized in using and creating open source software. I dream that Windows users and programmers were so open as Linux users. that's why I became interested in .NET and C#. I'm interested in cloud computing solutions too, so I know Windows Azure, where developers using Windows platform have an easier life... What is Mono status today? Is it posible to let Microsoft to help in developing Mono? Best regards, Michael ___ 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 ___ 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] To say hello and ask some questions about Mono...
On Tue, 2012-10-02 at 21:00 +0200, Michał Smereczyński wrote: Hello Leszek, W dniu 02.10.2012 20:04, Konrad M. Kruczyński pisze: Hi, do not hesitate to contact me if you like, but the idea seems rather vague to me. I have a lot of work lately... I plan to write to polish Mono developers (and C#/.NET/Mono programmers) and ask whether you want to start the Mono conference in Poland. The conference may be interesting. At least I would probably like to take part in it;) OK, but I often hear from my friends (programmers) that the Mono project is growing too slowly and because of their origin has some deficiencies that result from the lack of openness in Microsoft. Mono community is much smaller than... C++ or Python community in Linux World. I see your point. Situation is going better lately, for example Mono has already been noticed and respected by many OSS C# projects like ServiceStack, Nancy etc (which had their origins in .NET). The role of MonoTouch (and Android) and its popularity may be important reason here. Nonetheless it could always be better ;) -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ConcurrentQueueT issues (repros)
On Tue, 2012-09-25 at 16:57 +0300, Greg Young wrote: reviewing commits object pool is DEAD! and I don't mean 57005 :) Btw, some tests I did with and without object pool (by reverting introducing commit) showed that with SGEN it actually made things slower, therefore it is better option also from this point. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Google Summer of Code project ideas
Hi, I have an idea of Summer of Code project. I call it Smart usings for C#. I'm writing code not only in C#, but in Java too, and I noticed one difference between C# and Java IDEs: while most java IDEs can automatically add imports (usings in C#), it seems that only ReSharper can do it in C#. I think that it will be nice to have such feature in MonoDevelop. Actually, I'm feeling very uncomfortable when I have to manually type usings in MonoDevelop after writing code in Eclipse. Just a digression... Although I would appreciate ReSharper-like hints while typing in MD too, you do not really have to manually type usings even currently. After typing unqualified name you can right click on it and then go with Resolve and appropriate option (add using or make name fully qualified). I am pretty sure that this is the way used in Visual Studio without ReSharper installed. Usually I'm using MD built from the GIT master (or newresolver), but the feature is there for quite a long time. Or I did not understand what you meant. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Nuget and xbuild
Hi all,
during playing with nuget I discovered that xbuild has some problems
with playing with nuget's targets. Specifically nuget.targets contains
lines like that one:
PackagesConfig$([System.IO.Path]::Combine($(ProjectDir),
packages.config))/PackagesConfig
During the build one can see errors like that one:
Unable to locate '$([System.IO.Path]::Combine(/some/path, another/path))'
Is it that Combine is not executed at all but rather taken as a string?
Is it a bug?
I'm attaching whole nuget.targets.
--
Regards,
Konrad
?xml version=1.0 encoding=utf-8?
Project ToolsVersion=4.0 xmlns=http://schemas.microsoft.com/developer/msbuild/2003;
PropertyGroup
SolutionDir Condition=$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'$(MSBuildProjectDirectory)\..\/SolutionDir
NuGetToolsPath$([System.IO.Path]::Combine($(SolutionDir), .nuget))/NuGetToolsPath
NuGetExePath$(NuGetToolsPath)\nuget.exe/NuGetExePath
PackagesConfig$([System.IO.Path]::Combine($(ProjectDir), packages.config))/PackagesConfig
PackagesDir$([System.IO.Path]::Combine($(SolutionDir), packages))/PackagesDir
PackageOutputDir Condition=$(PackageOutputDir) == ''$(TargetDir.Trim('\\'))/PackageOutputDir
!-- Package sources used to restore packages. By default will used the registered sources under %APPDATA%\NuGet\NuGet.Config --
PackageSources/PackageSources
!-- Enable the restore command to run before builds --
RestorePackages Condition=$(RestorePackages) == ''false/RestorePackages
!-- Property that enables building a package from a project --
BuildPackage Condition=$(BuildPackage) == ''false/BuildPackage
!-- Commands --
RestoreCommand$(NuGetExePath) install $(PackagesConfig) -source $(PackageSources) -o $(PackagesDir)/RestoreCommand
BuildCommand$(NuGetExePath) pack $(ProjectPath) -p Configuration=$(Configuration) -o $(PackageOutputDir) -symbols/BuildCommand
!-- Make the build depend on restore packages --
BuildDependsOn Condition=$(RestorePackages) == 'true'
RestorePackages;
$(BuildDependsOn);
/BuildDependsOn
!-- Make the build depend on restore packages --
BuildDependsOn Condition=$(BuildPackage) == 'true'
$(BuildDependsOn);
BuildPackage;
/BuildDependsOn
/PropertyGroup
Target Name=CheckPrerequisites
!-- Raise an error if we're unable to locate nuget.exe --
Error Condition=!Exists('$(NuGetExePath)') Text=Unable to locate '$(NuGetExePath)' /
/Target
Target Name=RestorePackages DependsOnTargets=CheckPrerequisites
Exec Command=$(RestoreCommand)
LogStandardErrorAsError=true
Condition=Exists('$(PackagesConfig)')
WorkingDirectory=$(NuGetToolsPath) /
/Target
Target Name=BuildPackage DependsOnTargets=CheckPrerequisites
Exec Command=$(BuildCommand)
LogStandardErrorAsError=true
WorkingDirectory=$(NuGetToolsPath) /
/Target
/Project___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On Wed, 2012-02-01 at 22:04 -0200, Rodrigo Kumpera wrote: I expect it to be exposed to further internal usage and which will better shape it. I totally agree on this point. Maybe I could have some use on this via p/invoke to itself (using __Internal). What do you think? -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
Hi all, I think I was misunderstood. This is not beginner's question on how to write classes with Disposable pattern (you mentioned) -- believe me, I know that very well. Problem is rather as follows. Let's say we have an object whose life is short - it is collected on first GC scan after creation. But then if it has a finalizer it is not collected. Instead, it is marked for finalization. After some time its finalizer is called. And it is finally collected after next GC scan - so much more later than in the first case. Things will get worse if it will be promoted to next generation in the meantime. In other words such kind of object with finalizer will stay in memory longer than it should and that is the source of performance problems I mentioned. It can also hold reference to another (fully managed) objects, that one to another and so on. This is well known problem with objects implementing finalizers and one of the reasons (among unpredictability) for recommending explicit (via Dispose) release. But how can one do that if object is shared (the thing you would, for instance in C++, do with reference counting)? Finalizers are best as back-ups for such release, not the main mean, as you have written. I think that callback after death mechanism is the solution here. About the I/O operation invoked - I would not put it in the callback directly, rather enqueue it in thread pool. Oh, I've just found an article which talks about what I exactly meant: http://www.bluebytesoftware.com/blog/2011/11/12/ABriefNoteOnObjectMortality.aspx Apparently this is possible in Java. It could be therefore useful also for IKVM, as it has to be provided by it. I do not know how it is implemented in it currently - probably using small objects with finalizers on which they make proper notifications. I hope it is clearer now. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On Mon, 2012-01-23 at 23:35 -0200, Rodrigo Kumpera wrote: There is no specially collector for finalizable objects. The finalizer will be called around the same time the callback for such an object would be. I meant the sgen equivalent of the f-reachable queue. Callback will be called around the same time, I agree, but the object itself (with the one it points) can stay in memory longer. Even if performance was backed in, it would not help a lot since you have the large bottleneck of file backed. As I said, I would rather not delete file directly on the callback's thread, but queue its deletion. Also the mentioned approach can be useful for other kinds of resources. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Reference queue
Hi, I've just noticed that runtime offers mono_gc_reference_queue_new function, which can be used to register callback executed after object is collected. Is there a possibility of exporting this functionality to class library to have it available from C# code? (Mono.Runtime or sth like that). Btw, I would also like to bump on my thread Stopwatch's frequency at which no one responded. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
Thanks for the answer. Here is the case: Let's say I have a class which contains some data in temporary file (for example some kind of cache which should not stay in memory). I'd like to have this file removed when object of this class dies. I can implement a finalizer but if I do this, object will be reclaimed later than it should, also putting additional pressure on GC. Problems of objects with finalizers which are not manually invoked are generally known. And this is scenario where such object can be shared and does not fit into any kind of using block. I think that mentioned API can resolve that kind of problems, because I can set up a callback which deletes temporary file *after* object's death. Therefore it is processed like any other object, without being in special collection for disposable objects. I think it would bring significant performance gain, especially if objects are created often and we expect they die soon. It should be measured, but for that I need some kind of API. What do you think? We've thought about exporting such interface, but the maintenance burden made us back off. This interface has some short-coming and exposing it to managed code has it's problems. For example, it doesn't support unregistering. But, if you make your case on why such a feature would help you, I can look into it. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Stopwatch's frequency
Hi, lastly I've explored Stopwatch class implementation in Mono. It seems that it has hardcoded 100ns resolution. However examining mono_100ns_ticks function reveals that is written well and uses platform specific high resolution timer. My question is: why the initializer of the Frequency field (as well as the IsHighResolution) is not some internal call to check hr frequency using something like clock_getres? I'd like to submit pull request with patch doing just that if I find enough time, but first I would like to ask whether it would be accepted. Are there some reasons for the current implementation? -- Regards, Konrad Kruczynski ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono numerical performance
Hi, I'd like to add that you may gain something on MS JIT compiler using for (int i = 0 ; i x.Length ; i++) instead of for (int i = 0 ; i len ; i++) This may seem counter intuitive, however that's the scenario in which JIT eliminates array bound checking for the x array (however not for the second one) as arrays have constant length. I am not sure whether Mini recognizes that. I'm pretty sure that Hotspot is much smarter here ;) As Zoltan wrote in the bug comments, enabling LLVM improves the results a lot. This is, I guess, due to much better register allocation in which domain Mini isn't too good - and probably other optimizations like better loop unrolling. If I remember correctly, there once was a branch of LLVM with array bounds check elimination, is it still developed? I am also curious which code patterns enable ABC elimination in Mini. On Sun, 2011-11-20 at 08:01 -0500, Jonathan Shore wrote: Here is a link to and entry in bugzilla with attached code. I could not send to the list: http://bugzilla.xamarin.com/show_bug.cgi?id=2098 -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono numerical performance
Hi again,
It is too bad that one cannot declare a primitive expression to be
locally const in C#.
Maybe one could get away with something like this:
public struct FinalBoxT
{
public FinalBox(T value)
{
this.value = value;
}
public T Value
{
get
{
return value;
}
}
public static implicit operator T(ReadOnlyBoxT box)
{
return box.value;
}
private readonly T value;
}
Such construct may inform JIT that given value won't change (if
getter/operator is inlined which I hope happens). And with implicit
operator it's quite usable.
--
Regards,
Konrad
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono numerical performance
On Sun, 2011-11-20 at 12:33 -0500, Jonathan Shore wrote: Yes, I see what you are doing. There is no way to modify the structure. However doesn't it still boil down to determining whether a local variable reference is changed. Yeah, exactly, this is rather pointless construct ;) There should be no reference here (as this is struct) and can't be modified via its interface but the whole structure can be overwritten (which in this case is identical to field). int is in fact exactly such struct. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono numerical performance
On the other hand, maybe it could be possible to add the final-like mechanism to Mono's compiler. Such mechanism would be beneficial if the CLR had some notion of local readonly variables. F# uses non-mutable variables a lot, so maybe CLR recognizes it. I am not sure what kind of transparent denotation could be used - maybe some kind of comment, like it was done in MS Java in the pre-annotations days. Does Mono team see this as something worth considering? Probably proper analysis of assignments is a better idea. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono numerical performance
On Sun, 2011-11-20 at 19:39 +0100, Dawid Weiss wrote:
As far as I know the final on local variables is only a hint for the
java compiler (javac), not jit (hotspot) engine. Detection of loop
invariants is done at runtime (during code jitting) so there's really
no difference between any of the following in modern Java jits:
Maybe that's the reason there is no local readonly in the C# language -
local variables are easily trackable. As to those used in closures (as
mentioned by Jonathan) - as far as I know, they aren't local variables
actually but rather fields in compiler-generated class which represents
closure.
Btw, about the documenting intent part - some of these cases may
probably be covered by the Code Contracts.
1) (final) int max = array.length;
for (int i = 0; i max; i++) {}
2) for (int i = 0; i array.length; i++) {}
Yes, hotspot does really good analysis these days.
--
Regards,
Konrad
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] LLVM with current Mono
Hi, which branch of mono's LLVM repository should I use to compile mono 2.10.6 with --enabled-llvm? mono-2-10 one gives me: mini-llvm-cpp.cpp: In function ‘LLVMOpaqueExecutionEngine* mono_llvm_create_ee(LLVMOpaqueModuleProvider*, unsigned char* (*)(LLVMOpaqueValue*, int), void (*)(LLVMOpaqueValue*, void*, void*), void (*)(void*))’: mini-llvm-cpp.cpp:469: error: cannot allocate an object of abstract type ‘MonoJITMemoryManager’ mini-llvm-cpp.cpp:59: note: because the following virtual functions are pure within ‘MonoJITMemoryManager’: /usr/include/llvm/ExecutionEngine/JITMemoryManager.h:115: note: virtual void llvm::JITMemoryManager::deallocateFunctionBody(void*) /usr/include/llvm/ExecutionEngine/JITMemoryManager.h:131: note: virtual void llvm::JITMemoryManager::deallocateExceptionTable(void*) Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in Mono System.Net.Socket (was: Re: COM, Threads and Mono)
On Thu, 2011-09-15 at 10:24 +0100, Andres G. Aragoneses wrote: This is not related to COM or Threads. Next time try to not hijack threads please :) OK ;) If nobody reviews the patch in a few days I would harass Gonzalo on IRC if I were you ;) (Although providing unit tests for the bug you're trying to fix may work better!) I was wondering about unit tests, but for this particular case they would need to set up local TCP server and client. Such test could therefore fail for many reasons, it is not as unit as the patch ;) But if you think, it should be added, it could be done. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HeapShot like GUI
Hi, is there some kind of HeapShot like GUI for Mono profiler? -- Regards, Konrad Kruczynski ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Warnings version conflict mono 2.10 xbuild
It happened to me when I had references to libraries compiled against 3.5 (which in turn referenced System etc.) in an assembly compiled against 4.0 (which referenced System too). In my case I could just recompile those libraries to 4.0. Hi all, I'm developing on windows in Visual Studio 2010. However, we made a build server(linux) that builds under mono (version 2.10 with xbuild). When I build on in VS, I don't receive any warnings. However, when building on linux i have 72 warnings of which the most of them are reference conflicts like: /opt/mono-2.10/lib/mono/4.0/Microsoft.Common.targets: warning : Found a conflict between : 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Using 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' reference. I'm building in .Net 4.0 and, as you can see, this is not an error but a warning, so building the project succeeds but with a huge ammount of warnings. Is there a chance this might be solvable such that these warnings don't show up cause I do prefer no warnings at all. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unable to build current master on Linux
Hi Leszek, I'm trying to build current master branch on Linux, today it keeps failing with (...) I can confirm that. Using git bisect I was able to find that first time compilation has been broken after 5c82e32b676 commit, i.e. using new versions of functions to moving and zeroing memory. Apparently author knew that, because few commits later one can found a commit to fix broken build - new functions are using old one there. There is one more commit dealing with this which probably should fix those new functions and therefore again setting project to use them. However it does not work for me and Leszek. Build is broken while one of the first uses of freshly built MCS, because it is the first attempt to run managed code and, therefore, modified garbage collector. What is more interesting, I wasn't able to fix the build by reverting last commit made to gc.c. This is strange, because effectively it should tell new functions just to use the old one. Maybe not everywhere. Probably Rodrigo Kumpera should check this out. Are there other able to reproduce this? -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unable to build current master on Linux
Hello again, I'm trying to build current master branch on Linux, today it keeps failing with (...) I just pulled from origin and discovered that it is fixed now by revert by grendello. And that's the reason, reverting gc.c did not fix build - it was just a coincidence. Sorry to bother you, it's building fine now. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] JIT register binding
Hi Miguel, Could you try the same code, but using LLVM as the code generation engine? As expected, llvm generation is as optimal, as can be seen: movsd 0x8(%ebx),%xmm4 movsd 0x8(%edi),%xmm1 subsd %xmm1,%xmm4 movaps %xmm4,%xmm1 mulsd %xmm1,%xmm1 movsd 0x10(%ebx),%xmm2 movsd 0x10(%edi),%xmm3 subsd %xmm3,%xmm2 movaps %xmm2,%xmm3 mulsd %xmm3,%xmm3 addsd %xmm1,%xmm3 movsd 0x18(%ebx),%xmm1 movsd 0x18(%edi),%xmm5 subsd %xmm5,%xmm1 movaps %xmm1,%xmm5 mulsd %xmm5,%xmm5 addsd %xmm3,%xmm5 No store operations and pointless data moves between register. I am not sure what technique is used by llvm, but probably some kind of graph coloring with foregoing register coalescing. But I do agree that it would be nice to fix it in the regular case. I think there are two problems here. One is that using llvm causes some cpu and memory overhead during compilation, so overall application performance can be lower. The other one is that using llvm is nonstandard: some people know that it can be used, however it is not as easy, because it does not come in package (maybe some USE flags can be used at gentoo). For instance, folks at alioth debian shootout aren't using llvm with mono; these tests are mainly computational and mono results are suboptimal. If somebody just glances at the result, he won't probably wonder whether there are some options to improve performance, such as llvm, or not. Some time ago I came across an article about generation time optimized version of graph coloring algorithm, used by llvm in their jit mode. Maybe some kind of that should be implemented. What algorithm is used currently? As I can tell by file name, it is probably linear scan, but there are couple versions of linear scan and one can find a couple of FIXMEs in the implementation so I don't know how complete is it. Btw, as I understood from the article, llvm has a special jit mode, where only low cost optimizations are used. Is that what mono is using? -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] JIT register binding
Hello all, lastly I was looking at n-body test on shootout (http://shootout.alioth.debian.org/u64q/performance.php?test=nbody) in the context of Mono. Program is very simple so it is a nice piece to analyze sources of performance problems. I've also contributed SIMD version, but it has minor meaning as it wasn't significantly faster than the usual one. I also made a comparison of performance of this test on Windows, using .NET. It took about 70% of time that Mono needed, that is little interesting as well. However reasons behind that can be interesting. I made small analysis of code emitted by JIT in both cases. Let's analyze a part of code, specifically instruction, which computes square of length of vector which is difference between positions of two bodies: double dx = bi.x - bj.x, dy = bi.y - bj.y, dz = bi.z - bj.z; double d2 = dx * dx + dy * dy + dz * dz; On .NET emitted jit code is: fld qword ptr [edx+4] fsubqword ptr [eax+4] fld qword ptr [edx+0Ch] fsubqword ptr [eax+0Ch] fld qword ptr [edx+14h] fsubqword ptr [eax+14h] // here we have differences in st - st(2) fld st(2) fmulst,st(3) fld st(2) fmulst,st(3) faddp st(1),st fld st(1) fmulst,st(2) faddp st(1),st Here one can see code generated by Mono's jit engine (here is used ATT notation, but it shouldn't be a problem while reading): fldl 0x8(%ebx) fldl 0x8(%edi) fsubrp %st,%st(1) fstpl -0x18(%ebp) fldl 0x10(%ebx) fldl 0x10(%edi) fsubrp %st,%st(1) fstpl -0x20(%ebp) fldl 0x18(%ebx) fldl 0x18(%edi) fsubrp %st,%st(1) fstpl -0x28(%ebp) // we have differences in three offsets from ebp (local variables) fldl -0x18(%ebp) fldl -0x18(%ebp) fmulp %st,%st(1) fldl -0x20(%ebp) fldl -0x20(%ebp) fmulp %st,%st(1) faddp %st,%st(1) fldl -0x28(%ebp) fldl -0x28(%ebp) fmulp %st,%st(1) faddp %st,%st(1) fstpl -0x30(%ebp) Similarly to .NET, Mono is holding pointers to objects bi and bj in registers (in Mono's case edi and ebx as one can see). There is however a important difference in fact that .NET treats registers (floating point stack positions) as local variables while Mono always stores result from registers to stack allocated memory. In fact, in these case, stack variables for dx etc can be fully eliminated and this is what .NET jit does. Optimization which should be adopted here is to bound local variables to registers if possible. On the amd64 architecture problem is very similar but with respect to xmm registers. Problem is very common for all programs that do a lot of computations. Agree, this may be minority of software runned on Mono, but still. Was anyone investigating such kind of optimization? Is it too hard to achieve due to nature of Mini or any other problems? If I was interested in providing such optimization what should be my introduction to Mini's code? Thanks in advance for answers, regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [MonoTouch] what happens with MonoTouch and Mono for Android now
On 2011-05-16 22:13, Mauricio Henriquez wrote: ...and that on Miguel blog was the suspected good news??mmm, very uncertain the mono future is... I really sad for the mono team situation and the decision of Attachamate, specially after such a great last couple of years of mono related products...just hope that at least the mono core survive and not be forced to re-write all my code in mmm java?...what else do we have? Good luck with the new endeavour guys Mauricio As can be read: Continue to contribute, maintain and develop the open source Mono and Moonlight components. As I understood, mono remains to be supported and will still be GPL. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] FULL-AOT problem in SUSE 11.2
Hello, On 2011-05-07 20:18, Zoltan Varga wrote: Hi, You don't need full-aot, it is full platforms where no JITting is possible, on normal platforms, it won't lead to much perf increase. Also, AOT does not increase performance, it only decreases startup speed, since it avoids JITting during application startup. Zoltan Minor annotation: can AOT be used with LLVM? If it can, it could improve performance quite considerably, if used with computation intensive code. On the other hand compilation being done by LLVM is pretty slow, therefore making it an ideal goal for AOT. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Pull requests on bug fixes
Hi, lastly I posted two pull requests corresponding to bugs founded in bugzilla. One of these has even already be closed, however nobody showed interesting in pulling my changes or rejecting them. Could anyone with privileges check it out? One can find requests here: https://github.com/mono/mono/pull/92 https://github.com/mono/mono/pull/93 -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
