Subscribe: Miguel de Icaza
http://tirania.org/blog/miguel.rss2
Added By: Feedage Forager Feedage Grade C rated
Language: English
Tags:
applications  bit  build  code  core  developers  float  floating point  llvm float  mac  mono  net core  net  point  time  windows  years 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Miguel de Icaza

Miguel de Icaza



Miguel de Icaza's Blog



Published: Wed, 11 Apr 2018 17:12:00 -0500

Copyright: Miguel de Icaza
 



How we doubled Mono’s Float Speed

Wed, 11 Apr 2018 21:12:00 -0500

My friend Aras recently wrote the same ray tracer in various languages, including C++, C# and the upcoming Unity Burst compiler. While it is natural to expect C# to be slower than C++, what was interesting to me was that Mono was so much slower than .NET Core. The numbers that he posted did not look good: C# (.NET Core): Mac 17.5 Mray/s, C# (Unity, Mono): Mac 4.6 Mray/s, C# (Unity, IL2CPP): Mac 17.1 Mray/s, I decided to look at what was going on, and document possible areas for improvement. As a result of this benchmark, and looking into this problem, we identified three areas of improvement: First, we need better defaults in Mono, as users will not tune their parameters Second, we need to better inform the world about the LLVM code optimizing backend in Mono Third, we tuned some of the parameters in Mono. The baseline for this test, was to run Aras ray tracer on my machine, since we have different hardware, I could not use his numbers to compare. The results on my iMac at home were as follows for Mono and .NET Core: Runtime Results MRay/sec .NET Core 2.1.4, debug build dotnet run 3.6 .NET Core 2.1.4, release build, dotnet run -c Release 21.7 Vanilla Mono, mono Maths.exe 6.6 Vanilla Mono, with LLVM and float32 15.5 During the process of researching this problem, we found a couple of problems, which once we fixed, produced the following results: Runtime Results MRay/sec Mono with LLVM and float32 15.5 Improved Mono with LLVM, float32 and fixed inline 29.6 Aggregated: Just using LLVM and float32 your code can get almost a 2.3x performance improvement in your floating point code. And with the tuning that we added to Mono’s as a result of this exercise, you can get 4.4x over running the plain Mono - these will be the defaults in future versions of Mono. This blog post explains our findings. 32 and 64 bit Floats Aras is using 32-bit floats for most of his math (the float type in C#, or System.Single in .NET terms). In Mono, decades ago, we made the mistake of performing all 32-bit float computations as 64-bit floats while still storing the data in 32-bit locations. My memory at this point is not as good as it used to be and do not quite recall why we made this decision. My best guess is that it was a decision rooted in the trends and ideas of the time. Around this time there was a positive aura around extended precision computations for floats. For example the Intel x87 processors use 80-bit precision for their floating point computations, even when the operands are doubles, giving users better results. Another theme around that time was that the Gnumeric spreadsheet, one of my previous projects, had implemented better statistical functions than Excel had, and this was well received in many communities that could use the more correct and higher precision results. In the early days of Mono, most mathematical operations available across all platforms only took doubles as inputs. C99, Posix and ISO had all introduced 32-bit versions, but they were not generally available across the industry in those early days (for example, sinf is the float version of sin, fabsf of fabs and so on). In short, the early 2000’s were a time of optimism. Applications did pay a heavier price for the extra computation time, but Mono was mostly used for Linux desktop application, serving HTTP pages and some server processes, so floating point performance was never an issue we faced day to day. It was only noticeable in some scientific benchmarks, and those were rarely the use case for .NET usage in the 2003 era. Nowadays, Games, 3D applications image processing, VR, AR and machine learning have made floating point operations a more common data type in modern applications. When it rains, it pours, and this is no exception. Floats are no longer your friendly data type that you sprinkle in a few places in your code, here and there. They come in an avalanche and there is no place to hide. There are so many of them, and they won’t stop coming at you. The “float32” runtime flag So a couple of years ago we d[...]



Fixing Screenshots in MacOS

Wed, 04 Apr 2018 20:44:00 -0500

This was driving me insane. For years, I have been using Command-Shift-4 to take screenshots on my Mac. When you hit that keypress, you get to select a region of the screen, and the result gets placed on your ~/Desktop directory.

Recently, the feature stopped working.

I first blamed Dropbox settings, but that was not it.

I read every article on the internet on how to change the default location, restart the SystemUIServer.

The screencapture command line tool worked, but not the hotkey.

Many reboots later, I disabled System Integrity Protection so I could use iosnoop and dtruss to figure out why screencapture was not logging. I was looking at the logs right there, and saw where things were different, but could not figure out what was wrong.

Then another one of my Macs got infected. So now I had two Mac laptops that could not take screenshots.

And then I realized what was going on.

When you trigger Command-Shift-4, the TouchBar lights up and lets you customize how you take the screenshot, like this:

(image)

And if you scroll it, you get these other options:

(image)

And I had recently used these settings.

If you change your default here, it will be preserved, so even if the shortcut is Command-Shift-4 for take-screenshot-and-save-in-file, if you use the TouchBar to make a change, this will override any future uses of the command.




Magic!

Wed, 21 May 2014 19:03:00 -0500

Mono has a pure C# implementation of the Windows.Forms stack which works on Mac, Linux and Windows. It emulates some of the core of the Win32 API to achieve this. While Mono's Windows.Forms is not an actively developed UI stack, it is required by a number of third party libraries, some data types are consumed by other Mono libraries (part of the original design contract), so we have kept it around. On Mac, Mono's Windows.Forms was built on top of Carbon, an old C-based API that was available on MacOS. This backend was written by Geoff Norton for Mono many years ago. As Mono switched to 64 bits by default, this meant that Windows.Forms could not be used. We have a couple of options, try to upgrade the 32-bit Carbon code to 64-bit Carbon code or build a new backend on top of Cocoa (using Xamarin.Mac). For years, I had assumed that Carbon on 64 was not really supported, but a recent trip to the console shows that Apple has added a 64-bit port. Either my memory is failing me (common at this age), or Apple at some point changed their mind. I spent all of 20 minutes trying to do an upgrade, but the header files and documentation for the APIs we rely on are just not available, so at best, I would be doing some guess work as to which APIs have been upgraded to 64 bits, and which APIs are available (rumors on Google searches indicate that while Carbon is 64 bits, not all APIs might be there). I figured that I could try to build a Cocoa backend with Xamarin.Mac, so I sent this pull request to let me do this outside of the Mono tree on my copious spare time, so this weekend I did some work on the Cocoa Driver. But this morning, on twitter, Filip Navarra noticed the above, and contacted me: @migueldeicaza We actually have a working Cocoa backend for Mono SWF (along with lot of fixes that we never ported upstream). It didn't make sense for us to release a big dump, but could be useful for your new effort...— Filip Navara (@filipnavara) February 20, 2018 Only time will be able to answer whether as a community the tech world can devise better and simpler tools for normal users to have their privacy protected by default. Snowden has succeeded in starting an important discussion and having software developers and their patrons react to the news. At Xamarin we build developer tools for Android and iOS developers. It is our job to provide tools that developers use on a day to day basis to build their applications, and we help them build these mobile applications. In the last year, we have noticed several changes in our developer userbase. Our customers are requesting both features and guidance on a number of areas. Developers are reaching to us both because there is a new understanding about what is happening to our electronic communications and also response to rapidly changing requirements from the public and private sectors. Among the things we have noticed: Using Trusted Roots Respectfully: For years, we tried to educate our users on what they should do when dealing with X509 certificates. Two years ago, most users would just pick the first option "Ignore the problem". Today this is no longer what developers do by default. Certificate Pinning: more than ever, developers are using certificate pinning to ensure that their mobile applications are only talking to the exact party they want to. Ciphersuite Selection: We recently had to extend the .NET API to allow developers to force our networking stack to control which cipher suites the underlying SSL/TLS stack uses. This is used to prevent weak or suspected ciphersuites to be used for the communications. Request for more CipherSuites: Our Mono runtime implements its own SSL/TLS and crypto stacks entirely in C#. Our customers have asked us to support new cipher suites on newer versions of the standards. Sometimes developers can use the native APIs we provide to achieve the above goals, but sometimes the native APIs on[...]