I'm working on a fairly straight-forward (school) project. It's a job-shop scheduler. It's single-threaded, it has very limited File I/O (it reads a small problem description, then it goes to work trying to build a solution). The CPU should be the bottleneck. There is no user input/GUI.
On my machine, in release mode, without the debugger - in 3 minutes of CPU time, my PC can generate/evaluate 20,000 different schedules for a particular problem.
On a comparable *nix machine, executed with mono, in 3 minutes of CPU time, the server manages to generate/evaluate 2,000 different schedules. It's 1/10th the speed. I've compared Python performance between my machine and this particular server and the throughput was nearly identical.
The only 'system' call that I could see as being different was a call to
Process.GetCurrentProcess().TotalProcessorTime.Minutes
But removing it hasn't had any impact.
I've tried using
--aot -O=all
It didn't have any noticeable impact.
I've also tried to run the mono profiler against it but the results haven't been as helpful as I had hoped.
Hits % Method name
57542 37.45 /usr/bin/mono
11432 7.44 __lll_unlock_wake in /lib64/libpthread.so.0
6898 4.49 System.Linq.Enumerable:Any<jobshop2.JobTask> (System.Collections.Generic.IEnumerable`1<jobshop2.JobTask>,System.Func`2<jobshop2.JobTask, bool>)
6857 4.46 System.Collections.Generic.List`1/Enumerator<jobshop2.JobTask>:MoveNext ()
3582 2.33 pthread_cond_wait##GLIBC_2.3.2 in /lib64/libpthread.so.0
2719 1.77 __lll_lock_wait in /lib64/libpthread.so.0
Of those top six lines - I only recognize two of them as being 'my code' that I could improve upon. In the full output I can see quite a few calls in /lib64/libpthread.so.0 that seem to deal with locking, unlocking, waiting, mutexes, and pthreads. I'm confused by this because it is not a multi-threaded application.
I'm going through the Performance page on the mono site but nothing is really jumping out at me as being a problem. I have no doubt that my code is ugly and slow, but I really wasn't expecting such a big performance drop. I'm currently trying to get Linux installed on my desktop so that I can run my app in mono on the same hardware to help eliminate that variable - but I thought someone might be able to offer some suggestions/insight.
EDIT:
It is version 2.10.8 mono
Mono JIT compiler version 2.10.8 (tarball Sat Feb 16 11:51:56 UTC 2013)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: debugger softdebug
LLVM: supported, not enabled.
GC: Included Boehm (with typed GC and Parallel Mark)
This is a bit of an awkward answer, but I felt like it was the most fair way to handle it...I can't really explain what the cause was, but I don't want to imply that mono is horribly slow (it really isn't).
My concern was getting the program to run fast on the server. As other people have pointed out, the version of mono installed on the server was very old. I hope nobody sees my question and thinks that it reflects the current state of mono. Sadly, I am not able to update the version of mono on the server.
So, I re-wrote my code to remove unnecessary computation, avoid using iterators, and to limit memory allocations. My original code was doing a lot of unnecessary creation of objects and the objects were a lot larger than they needed to be. The clean up doubled the speed on my machine and made the 'server' performance about 70% of my own (a huge improvement!).
Still, it's not fair to compare different hardware - even if previous Python programs 'seemed' to run at about the same speed. I installed Linux and, with the newest version of mono, installed, my revised program ran at 96% of the Windows version.
I didn't keep digging beyond that. Using the current version of mono, on the same hardware, gave me nearly identical performance. Thanks for all the suggestions, it was incredibly helpful and saved me a lot of time.
Could be a memory leak. Mono is fighting an uphill battle; Microsoft made a system and developers had to reverse-engineer most of it. If you really can't figure it out, I would try reporting the bug to the mono developers:
Bugs - Mono (http://www.mono-project.com/Bugs)
Make sure that your mono version is up to date first; 2.10 is ancient. As of now, 3.2.6 is the latest. The packaged version from a package maintainer might not be good enough; try building it from the source tarball, and using that to run your program, before reporting bugs.
If you are using wine-mono or something like that on linux, then make sure that wine and wine-mono are up to date as well.
Related
I've been looking into this bug for a week or so, and after all attempts to figure out how to fix it I still have not done so. That issue is the title of this post. When I go into my c# project and increment the AssemblyVersion to a newer version I get a small performance boost. When I decrement the AssemblyVersion, I get a large noticeable performance boost.
At this time I am working on an 64 bit machine with an AMD processor, and if I switch to an Intel machine (also 64 bit), this issue does not occur. The project I am working on is reliant on 2 or 3 Microsoft dlls and 1 dll created by someone who worked on this project in the past whom I can not contact (built in x86).
In VisualStudio 2013 I analyzed the performance when the Assembly version number was incremented, decremented, and kept the same. From what I could see it looked like the application on average was using less threads on the slower version, and having more collisions.
I am going to be honest and say I am picking up a project someone in the past was working on, and I am definitely a C# amateur. Because of this I have spent the past week or so trying to research exactly what the AssemblyVersion and AssemblyFileVersion are used for, how the AssemblyInfo.cs is built with the project, and how dlls are built with the project. Though I still am a little bit hazy on the facts. Here are a few places I have looked in my research about them:
DLL hell
Differences between assemblyversion assemblyfileversion and assemblyinformationalversion
Process Interoperability
Cross assembly causes performance hit
I have also run the Visual studio Performance and Diagnostics tool to try and visualize the cpu's strain graphically, and to see the number of times a function was called during the application's lifetime. All 3 options (increment, decrement, stay the same) had the function that runs the application (a timer that goes off every 50 ms) run more if it was a slower version, and less if it was a faster version.
I have tried rebuilding the dll being used with our project to x64 and building the project as Any CPU, but that too did not work. After that I hit a brick wall and have absolutely no idea where to look for more help / info about my problem I am encountering.
I am really sorry if this is difficult to answer from what I have given, or if anything is unclear. If anybody needs any clearer explanation, I will attempt to reply and do so. After 4 eastern though I wont be able to reply to questions until tomorrow in the morning.
Thanks everyone
edit* Performance measurements were made with the stopwatch class (bad idea I know). The performance is noticeably different in how fast the GUI will refresh the results on a page. (there are around 3-10 messages which can be displayed per second on the GUI)
I've a C# server developed on both Visual Studio 2010 and Mono Develop 2.8. NET Framework 4.0
It looks like this server behaves much better (in terms of scalability) on Windows than on Linux.
I tested the server scalability on native Windows(12 physical cores), and 8 and 12 cores Windows and Ubuntu Virtual Machines using Apache's ab tool.
The windows response time is pretty much flat. It starts picking up when the concurrency level approaches/overcomes the number of cores.
For some reason the linux response times are much worse. They grow pretty much linearly starting from level 5 of concurrency. Also 8 and 12 cores Linux VM behave similarly.
So my question is: why does it perform worse on linux? (and How can I fix that?).
Please take a look at the graph attached, it shows the averaged time to fulfill 75% of the requests as a function of the requests concurrency(the range bar are set at 50% and 100%).
I have a feeling that this might be due to mono's Garbage Collector. I tried playing around with the GC settings but I had no success. Any suggestion?
Some additional background information: the server is based on an HTTP listener that quickly parses the requests and queues them on a thread pool. The thread pool takes care of replying to those requests with some intensive math (computing an answer in ~10secs).
You need to isolate where the problem is first. Start by monitoring your memory usage with HeapShot. If it's not memory, then profile your code to pinpoint the time consuming methods.
This page, Performance Tips: Writing better performing .NET and Mono applications, contains some useful information including using the mono profiler.
Excessive String manipulation and Boxing are often 'hidden' culprits of code that doesn't scale well.
Try the sgen garbage collector (and for that, Mono 2.11.x is recommended). Look at the mono man page for more details.
I don't believe it's because of the GC. AFAIK the GC side effects should be more or less evenly distributed across the threads.
My blind guess is: you can fix it by playing with ThreadPool.SetMinThreads/SetMaxThreads API.
I would strongly recommend you do some profiles on the code with regards to how long individual methods are running. It's quite likely that you're seeing some locking or similar multi-threading difficulties that are not being handled perfectly by mono. CPU and RAM usage would also help.
I believe this may be the same problem that we tracked down involving the thread pool and the starting behavior for new threads, as well as a bug in the mono implementation of setMinThreads. Please see my answer on that thread for more information: https://stackoverflow.com/a/12371795/1663096
If you code throws a lot of exceptions, then mono is 10x faster than .NET
Is there a performance difference between 32-bit and 64-bit operating system when I use Visual Studio 2010 ? (Mostly working with .NET and C#)
don't know all implication, but one major benefits of the 64bits is that the process can go further than 2GB of memory.
When you have dozens of plugins, or large projects with heavy process (Resharper real-time analysis for my experience), this can be a large benefits to go beyond 2GB of ram.
Also, 64bits will allow you to beyond the <4GB limitation of the OS..
Taking a risk answering this, I think, but...
Visual Studio is only available in 32-bit, and so runs as such in either environment. I'm certain Windows is very well optimised for running 32-bit applications in the WOW64 emulator.
Indeed, it performs well enough for me to be productive.
For some information on this from MSDN, check here; neatly, this states:
Processor hardware. Instruction
emulation is performed on the chip. On
the x64 processor, instructions are
executed natively by the
micro-architecture. Therefore,
execution speed under WOW64 on x64 is
similar to its speed under 32-bit
Windows. On the Intel Itanium
processor, more software is involved
in the emulation, and performance
suffers as a result.
Though this is not an exhaustive explanation. The link covers more ground regarding the variability.
Here at work, he have 32 bit and 64 bit boxes, some with Windows XP, some with Windows 7. Even though we work with quite big solutions, I can assure you that we can't notice any significant difference in performance. Nevertheless, #SteveB's right about going beyond the memory limitation, so I'd say go 64 bits.
We recently moved from Windows XP to Windows 7. We found that one part of application in C# that try to create a dbf file for a PDA failed thorwing an error message
"The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."
I found many forums pointing me to build my exe as 32 bit like here.
My Question No. 1) Is there any other driver for accessing dbf on a 64 bit OS machine? (I know there is one for accessing excel and access db). Anything there for dbf?
Question No 2. same as my Title. I have a feeling that by converting to 32 bit, I am not making use of the full advantage of a 64 bit. so What am I losing by this workaround?
Thanks in Advance.
x64 processes have access to more instructions and more registers. By compiling for x86 vs Any CPU you give up the ability for the JIT compiler to use those instructions and registers (and more memory), typically resulting in a (small) performance penalty. But really, 99 times out of a hundred your users won't notice.
What they will notice is that your program doesn't work if you compile it for Any CPU because there is no 64bit OLE driver for dbf files. This format is not used as much any more, and so it wouldn't surprise me to learn that Microsoft has not written and has no plans to build the 64bit version.
In response to your second question, 64-bit doesn't get you that much unless you want to store huge amounts of data in memory. Most developers still target x86 (32-bit) because there's a lot less hassle with it. That said, there are cases when 64-bit systems operate better but, as I said, it's mainly to do with the amount of memory you want to consume.
In response to your first question, a 64-bit machine attempting access on a database with 32-bit software through the MS engines needs to have the Data Connectivity Components installed:
http://www.microsoft.com/downloads/en/details.aspx?familyid=7554f536-8c28-4598-9b72-ef94e038c891&displaylang=en
With x86 you are saving memory and making it easier to use Edit-and-Continue. On the minus side you are limiting your address space. See some rationales for 1) not making VS 64-bit and 2) making the default for new apps created in VS 32-bit:
1: http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx
2: http://blogs.msdn.com/b/rmbyers/archive/2009/06/8/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx
Plus:
http://blogs.msdn.com/b/maoni/archive/2007/05/15/64-bit-vs-32-bit.aspx
I cannot answer question No 1. but as for No 2 the answer is probably "it depends". Heavy mathematical operations (e.g. cryptography) can get a significant speed boost in 64 bit systems if implemented properly. And also you'll be able to address more memory (but that is probably not an issue if you're not using massive amounts of memory).
In other cases I have actually seen small slowdowns for 64-bit applications compared to building them as 32-bit applications (probably due to some overhead related to larger addresses).
I created a simple hello world mono touch (iPhone) application. However, its size is 5MB.
Is there a way to make it smaller?
This is from the mailing list post today:
In addition to this thread, I wanted to give folks a heads up on
what we have been up to with MonoTouch and disk/memory usage.
New ARM optimizations.
In the upcoming version of MonoTouch, a new ARM optimization will
for example reduce mscorlib native code by 300k. So it will go from
800k to 500k. You can expect the same kind of savings in other
assemblies as well.
This was implemented by a technique that reuses many of the wrapper
functions that Mono uses to shared wrappers.
Enhanced Linker
The linker is improving, and it will no longer for example pull any
of Mono.Security.dll, unless you use the http stack. This in the
example below will remove some 300k from the final distribution as
well.
The linker is still too conservative, and we will continue to enhance it to be more aggressive and remove more code.
In general
Since we started, one of our goals to ensure that we would have a
small footprint, so we invested significant time on our linker, and we
continue to invest in it.
Mono apps on the IPhone include the Mono runtime so you can't really get much smaller than 5mb. See this related question
EDIT: As per Miguel's answer, it appears the minimum footprint is about to shrink considerably.
Try using the linker options. Link SDK only or Link all assemblies.