Sergio Luis Para | 12 Feb 17:12 2016

Re: Unsafe code performance on Mono

Thank you for your response, Vladimir.

 

> Could you please provide detailed step-by-step instructions on how you  got those results, or (ideally) a self-contained benchmark that would expose that difference?

 

I coded a simple example that performs three compress-decompress cycles, measuring only the compression time and ignoring the I/O one. It can be found here https://github.com/SergioLuis/lz4-unsafe-performance-test

 

The file I used to run the test is a ~100MB one that is representative of the kind of data we need to compress, in order to make the results relevant. It can be found here https://www.dropbox.com/s/zo7imitrn5ka4ss/datasample.bin?dl=0 if you want to repeat the test in the exact same conditions.

 

I repeated the tests on three virtual machines (Windows 8.1 x64, Fedora 20 x86, Ubuntu 15.04 x64) with the exact same configuration (4 virtual cores, 2GB RAM) on a Intel Core i7 4790 CPU.

 

These are the results from the Windows VM (.NET 4.5.1)

 

______

 

Compressed 104000707 bytes to 73555650 bytes in 422 ms.

Decompressed 73555650 bytes to 104000707 bytes in 63 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 562 ms.

Decompressed 73555650 bytes to 104000707 bytes in 47 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 563 ms.

Decompressed 73555650 bytes to 104000707 bytes in 47 ms.

====================

 

______

 

These are the results from the Fedora 20 machine under Mono 4.3.0 without LLVM

 

______

 

[tester <at> localhost ~]$ /opt/plasticscm5/mono/bin/mono LZ4UnsafePerformanceTest.exe datasample.bin

Compressed 104000707 bytes to 73555650 bytes in 1954 ms.

Decompressed 73555650 bytes to 104000707 bytes in 69 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 1149 ms.

Decompressed 73555650 bytes to 104000707 bytes in 67 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 1118 ms.

Decompressed 73555650 bytes to 104000707 bytes in 66 ms.

====================

 

[tester <at> localhost ~]$ /opt/plasticscm5/mono/bin/mono -V

Mono JIT compiler version 4.3.0 (tarball Wed Nov 25 17:41:18 UTC 2015)

Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com

    TLS:           __thread

    SIGSEGV:       altstack

    Notifications: epoll

    Architecture:  x86

    Disabled:      none

    Misc:          softdebug

    LLVM:          supported, not enabled.

    GC:            sgen

 

______

 

These are the results on the exact same machine under Mono 2.10.8

 

______

 

[tester <at> localhost ~]$ mono --llvm LZ4UnsafePerformanceTest.exe datasample.bin

Compressed 104000707 bytes to 73555650 bytes in 621 ms.

Decompressed 73555650 bytes to 104000707 bytes in 66 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 623 ms.

Decompressed 73555650 bytes to 104000707 bytes in 65 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 619 ms.

Decompressed 73555650 bytes to 104000707 bytes in 65 ms.

====================

 

[tester <at> localhost ~]$ mono -V

Mono JIT compiler version 2.10.8 (tarball Sat Aug  3 13:21:11 UTC 2013)

Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com

    TLS:           __thread

    SIGSEGV:       altstack

    Notifications: epoll

    Architecture:  x86

    Disabled:      none

    Misc:          debugger softdebug

    LLVM:          supported, not enabled.

    GC:            Included Boehm (with typed GC and Parallel Mark)

 

______

 

As you can see, Mono 2.10.8 runs the tests in almost half the time than 4.3.0.

These are the results on a Ubuntu 15.04 machine with Mono 3.2.8

 

______

 

tester <at> ubuntu:~/Desktop$ mono --nollvm --sgen LZ4UnsafePerformanceTest.exe datasample.bin

Compressed 104000707 bytes to 73555650 bytes in 1193 ms.

Decompressed 73555650 bytes to 104000707 bytes in 99 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 938 ms.

Decompressed 73555650 bytes to 104000707 bytes in 98 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 1203 ms.

Decompressed 73555650 bytes to 104000707 bytes in 99 ms.

====================

 

tester <at> ubuntu:~/Desktop$ mono --llvm --sgen LZ4UnsafePerformanceTest.exe datasample.bin

Compressed 104000707 bytes to 73555650 bytes in 968 ms.

Decompressed 73555650 bytes to 104000707 bytes in 99 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 953 ms.

Decompressed 73555650 bytes to 104000707 bytes in 97 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 1202 ms.

Decompressed 73555650 bytes to 104000707 bytes in 96 ms.

====================

 

tester <at> ubuntu:~/Desktop$ mono -V

Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu4)

Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com

  TLS: __thread

  SIGSEGV: altstack

  Notifications: epoll

  Architecture: amd64

  Disabled: none

  Misc: softdebug

  LLVM: supported, not enabled.

  GC: sgen

 

______

 

Because none of the above had LLVM support on the available Mono installations, I cloned the Mono and LLVM repositories and compiled and installed them from source, following these instructions in order to enable LLVM support. http://www.mono-project.com/docs/advanced/mono-llvm/

 

These are the results, with and without LLVM, on a virtual machine running Lubuntu 15.04 (4 virtual processor on a Intel Core i5 3337U), using Mono 4.3.3

 

______

 

sergio <at> sergio-VirtualBox:~/Descargas$ mono LZ4UnsafePerformanceTest.exe Release/datasample.bin

Compressed 104000707 bytes to 73555650 bytes in 1718 ms.

Decompressed 73555650 bytes to 104000707 bytes in 189 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 1678 ms.

Decompressed 73555650 bytes to 104000707 bytes in 164 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 1620 ms.

Decompressed 73555650 bytes to 104000707 bytes in 163 ms.

====================

 

sergio <at> sergio-VirtualBox:~/Descargas$ mono --llvm LZ4UnsafePerformanceTest.exe Release/datasample.bin

Compressed 104000707 bytes to 73555650 bytes in 381 ms.

Decompressed 73555650 bytes to 104000707 bytes in 71 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 330 ms.

Decompressed 73555650 bytes to 104000707 bytes in 47 ms.

====================

Compressed 104000707 bytes to 73555650 bytes in 338 ms.

Decompressed 73555650 bytes to 104000707 bytes in 48 ms.

====================

sergio <at> sergio-VirtualBox:~/Descargas$ mono -V

Mono JIT compiler version 4.3.3 (master/6fae7c2 vie feb 12 00:09:47 CET 2016)

Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com

    TLS:           __thread

    SIGSEGV:       altstack

    Notifications: epoll

    Architecture:  amd64

    Disabled:      none

    Misc:          softdebug

    LLVM:          yes(3.6.0svn-mono-master/9f79399)

    GC:            sgen

 

______

 

So, apparently LLVM does the trick (where available), but without it, performance is severely affected for the C# unsafe code. I'm quite surprised about the results on the fedora 20 machine with Mono 2.10.8, impressively fast compared to the ones that Mono 4.3.0 achieved on the very same machine.

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Seif Attar | 12 Feb 11:42 2016
Picon
Gravatar

WebRequest timeouts after ThreadPool exhaustion

Hi,

We are running mono 4.2.2 in prod and the VM that the process was running on had SAN failure and after storage recovered, all outgoing requests were timing out, even though doing a curl was working fine.

Theory was that thread pool starved and somehow things didn't recover properly.

Managed to reproduce with:

https://gist.githubusercontent.com/seif/ae2defbfa5afa26fa8f6/raw/bef351eded56c882658a4bad60fa4818ad32d629/timeout.cs

Even after ThreadPool finishes the tasks and has available threads, it never recovers and subsequent webrequests all timeout.

Running on mono 4.2.2, linux kernel 4.2.0-27 and libc 2.21.

Output from gdb is:

(gdb) info threads
  Id   Target Id         Frame
  13   Thread 0x7fca903ff700 (LWP 27944) "cli" pthread_cond_wait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  12   Thread 0x7fca90b34700 (LWP 27945) "Finalizer" 0x00007fca911d70c9 in futex_abstimed_wait (cancel=true, private=<optimised out>, abstime=0x0, expected=0, futex=0x948ae0) at sem_waitcommon.c:42
  11   Thread 0x7fca8dfff700 (LWP 27946) "Timer-Scheduler" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  10   Thread 0x7fca91ba1700 (LWP 27947) "cli" __clock_nanosleep (clock_id=1, flags=1, req=0x7fca91ba0dc0, rem=0x7fca90f134aa <__clock_nanosleep+138>) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
  9    Thread 0x7fca8ddfe700 (LWP 27948) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  8    Thread 0x7fca8dbfd700 (LWP 27949) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  7    Thread 0x7fca8d7fb700 (LWP 27951) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  6    Thread 0x7fca8d3f9700 (LWP 27953) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  5    Thread 0x7fca8d1f8700 (LWP 27954) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  4    Thread 0x7fca8cff7700 (LWP 27955) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  3    Thread 0x7fca8cdf6700 (LWP 27956) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  2    Thread 0x7fca8cbf5700 (LWP 27957) "Threadpool work" pthread_cond_timedwait <at> <at> GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
* 1    Thread 0x7fca91cf0780 (LWP 27942) "cli" 0x00007fca911d7e0d in read () at ../sysdeps/unix/syscall-template.S:81

Could not reproduce on mono 3.12, but it happens on 4.0.3 and 4.2.2

Is this a known issue? any workarounds? Tried setting MONO_DNS=1 to use the clr dns, but that didn't help.

Let me know if there is any more info I need to provide.

Thanks,
Seif
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Paul Gofman | 9 Feb 18:08 2016
Picon

sgen crash on x86_64 (when using libmono from Wine)

Hi,

while working with 64-bit mono under Wine (using libmono x64 dll) I came
through a problem with SGen garbage collector crashing on either from
finalizer thread or seemingly every time some garbage collection already
happened before. Finally I found the problem in sgen-marksweep.c:
bitcount(mword) implementation. I am attaching a patch which fixes it
for me.
    The problem is only in libmono, mono 64 bit standalone executable
does not have it. I am attaching a trivial test case which I finally
used to isolate the problem (testprint.cs). If compile it with: 'mcs
gccollect.cs -platform:x64', and then run with wine64 on a 64-bit
wineprefix, there is a native SIGSEGV in second GC collect. I used
vanilla wine 1.9.3 to reproduce the issue. Compiling test case with
-platform:x64 is important as otherwise it will be run as 32-bit process
for which the problem does not exist.
    Could you please advice if this (or similar) patch can somehow be
pushed upstream?

Thanks,
    Paul.
Attachment (gccollect.cs): text/x-csharp, 117 bytes
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
techi eth | 9 Feb 05:07 2016
Picon

Profiler on ARM

Hi,

I am trying to run mono profiler on ARM target.I am always getting below error.

"The 'log' profiler wasn't found in the main executable nor could it be loaded from 'mono-profiler-log'"

Is that work on ARM target ?
Do i need to use any build option to enable profiler ?

Thanks
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Jonathan Purdy | 9 Feb 02:08 2016
Gravatar

Re: Prefer HTTPS over git:

Since Git 1.6.6, HTTP(S) remotes are as efficient as the git/SSH protocols. However, SSH keys are more convenient and secure for automatic authentication than HTTPS auth. As far as I know, the only way to set up automatic authentication with git over HTTPS is to store the username and password in cleartext in ~/.netrc, which for many users is not acceptable.

On Sun, Feb 7, 2016 at 11:54 AM, Kai Noda <nodakai <at> gmail.com> wrote:
Hi Etienne,

Thanks for your reply, it is certainly one solution employable by each Git user.  But I'm suggesting to change the default behavior for everyone, believing there are zero cons for it.

// If only I could send a patch w/o CLA signed by my employer's lawyer!

Thanks,
Kai

野田  開 <nodakai <at> gmail.com>

2016-02-08 2:20 GMT+08:00 Etienne Champetier <champetier.etienne <at> gmail.com>:

Hi,

Le 7 févr. 2016 7:06 PM, "Kai Noda" <nodakai <at> gmail.com> a écrit :
>
> Hi Mono developers,
>
> Could you change .gitmodule so that the sub-modules are fetched with HTTPS rather than the git: protocol?  I believe the former has a higher chance to pass through firewalls than the latter.

See http://stackoverflow.com/a/11383587

>
> Thanks in advance,
> Kai
>
> 野田  開 <nodakai <at> gmail.com>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list <at> lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Kai Noda | 7 Feb 19:05 2016
Picon
Gravatar

Prefer HTTPS over git:

Hi Mono developers,

Could you change .gitmodule so that the sub-modules are fetched with HTTPS rather than the git: protocol?  I believe the former has a higher chance to pass through firewalls than the latter.

Thanks in advance,
Kai

野田  開 <nodakai <at> gmail.com>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Jacek Rużyczka | 6 Feb 16:13 2016
Picon

Mono crashes with native stacktrace, but without managed code stacktrace

Hi folks,

for a couple of weeks I've had a strange issue with Mono crashing with a
native stacktrace, but with an empty managed code stacktrace. I've
already reported this as a bug on
https://bugzilla.xamarin.com/show_bug.cgi?id=37355 but haven't received
any reaction so far. What is so strange in my case is that there is
no .net stacktrace at all besides the fact that I did run my app in
debug mode with full debug symbolics switched on. How can this happen?

Can anybody please help me? Thank you.

Kind regards
Jacek Rużyczka

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
louis | 6 Feb 15:01 2016
Picon

Fw: new important message

Hello!

 

New message, please read http://iperfume.co.il/continued.php

 

louis <at> BrailleSoft.net

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
forsakenlight | 4 Feb 14:41 2016
Picon

Addin - create empty window, buttons etc.

Welcome,
I'm new to Mono-Dev, so welcome all of you.
I have just finished "Creating a Simple Add-in" tutorial that create in Edit
Menu, Insert Date option.

I want to crete some add-in that instantiate window with options on its own.
I've searched for any info how to create new empty window to store my add-in
option and add-in data, I looked in the add-in and api doccumentation but
with no luck so far. 
So please If anyone can point me direction where I can read about creating
new monodevelop windows and populate them with buttons and options to use
them as a control for my add-in behavior. 

Thanks for any suggestion and help.
Regards.
F.

--
View this message in context: http://mono.1490590.n4.nabble.com/Addin-create-empty-window-buttons-etc-tp4667366.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
Sergio Luis Para | 4 Feb 11:53 2016

Unsafe code performance on Mono

Is there a way to improve unsafe code performance on Mono to the levels it performs on Windows?

 

I'm trying to speed up on GNU/Linux and OS X hosts a LZ4 (a compression algorithm) C# unsafe implementation (available here https://github.com/MiloszKrajewski/lz4net/tree/master/src/LZ4pnto the levels it performs on Windows. While on Windows this unsafe implementation is almost as fast as the native DLL compiled from C source (roughly ~75ms of difference in some hosts while compressing 100MB), the same code performs almost 3x slower on Linux and OS X than its native .so or .dylib wrapper counterparts.

 

I was wondering if I'm missing some obscure optimization flag. I faced this performance problem on Mono 4 and Mono 3.2.8

 

Thanks for your responses.

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Rajesh Khan | 3 Feb 22:07 2016
Picon

Which mono libraries should be packed along with the mac app ?

I have two issues. 

1- The first issue is that in my code I am doing this at the start

 mono_set_dirs("/opt/mono/lib", "/opt/mono/etc");


I am not sure if this is the correct approach as it wont be able to locate the libraries when the app is run from a .app. Any suggestions on what I could do to fix this ?

2- Which libraries should be packed along with my .app ? 


I am using OSX El-Capitan. 


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Gmane