I am trying to compare the performance of a specific F# benchmark running on .NET and Mono 2.10.2 (Windows 7, 64-bit). I took the Spectral-Norm benchmark from the Benchmarks Game followed the traditional SO advice of using System.Diagnostics.StopWatch for benchmarking C# and added the lines 4, 89-90, and 93-95 at this link. I compiled this code in Visual Studio 2010 (For runtime 4.0, not client profile, any CPU, with optimize code and tail calls turned on). The compiled code runs just fine on .NET (including inside VS), but when I run the .exe on Mono with "mono shootout_spectralnorm.exe" I get the following error (repeated in the fssnip.net link):
Unhandled Exception: System.TypeInitializationException: An exception was thrown
by the type initializer for System.Diagnostics.Stopwatch ---> System.InvalidPro
gramException: Invalid IL code in System.Diagnostics.Stopwatch:.cctor (): method
body is empty.
--- End of inner exception stack trace ---
at Program.main (System.String[] args) [0x00000] in <filename unknown>:0
The strange thing is, when I remove the lines I had added (lines 4, 89-90, and 93-95, which relate to the timing part of the benchmark), the error goes away on Mono, and it acts just like it does on MS .NET. This is just baffling me. I set all of the referenced assemblies in VS to be copied locally, so they should be visible to Mono, but there could be some precedence issue with different assemblies in the GAC that have the same name as the ones in the local folder. Has anyone encountered this issue or a similar one, especially on Windows Mono? If so, or if you think you know how this problem could be fixed, I hope you can help me resolve it.
Reference Assemblies do not (often) have code - they are API signatures only (enough info for the compiler to reference them at design-time/compile-time). You need to copy the runtime assemblies, not the reference assemblies, in order to run it. (You'll often find the runtime assemblies in the GAC.)
Here are measurements for FSharp-2.0.0.0 spectral-norm #2 (Intel Q6600 quad-core, MS Vista 32 bit)
fsc CPU s Elapsed s
500 0.281 0.337
3000 4.883 1.453
5500 15.85 4.212
2.10.2 CPU s Elapsed s
500 0.343 2.222
3000 4.836 3.361
5500 15.912 6.153
C:/Mono-2.10.2/bin/mono.exe C:/FSharp-2.0.0.0/bin/fsc.exe --platform:x86
--optimize+ --out:spectralnorm.exe spectralnorm.fsharpmono-2.fs
C:/Mono-2.10.2/bin/mono.exe --gc=sgen spectralnorm.exe 5500
Now the benchmarks game spectral-norm on MS Vista demo, includes F# on Mono.
Related
I'm getting this error
error FS0073: internal error: tcrefOfAppTy (Failure)
reported on this code
type ``Children``<'a> = abstract member ``Children`` : Unit -> 'a
[<Extension>]
type Extensions =
[<Extension>]
static member Children<'A, 'B when 'A :> ``Children``<'B>> (this: 'A) =
this.Children()
let f2 a =
a.Children()
apologies for the strange code, this is part of a much much bigger project with literally hundreds if not thousands of types (I'm wondering if that's the problem somehow)
This code DID used to compile on azure devops on a "windows-2019" box, with dotnet core 3.x, against F# 5.0
It doesnt compile (this project) on "windows-2022" box, since ive upgraded it to dotnetcore 6.0, F# 5, using a fake script. I notice the azure box uses visual studio enterprise
MSBuild version 17.3.0+f67e3d35e for .NET Framework
This code in this upgraded state, does compile in visual studio 2022, on my laptop, windows 11 pro.
And also the same fake script works, though my machine has this
Microsoft (R) Build Engine version 17.2.1+52cd2da31 for .NET Framework
and runs visual studio professional.
The devops logs contain this: (which looks a bit worrying)
Unhandled Exception: System.Exception: tcrefOfAppTy
2022-08-29T10:32:08.1995442Z at FSharp.Compiler.TypedTreeOps.tcrefOfAppTy(TcGlobals g, TType ty) in D:\a\_work\1\s\src\Compiler\TypedTree\TypedTreeOps.fs:line 877
2022-08-29T10:32:08.1997298Z at FSharp.Compiler.AttributeChecking.CheckMethInfoAttributes[a](TcGlobals g, Range m, FSharpOption`1 tyargsOpt, MethInfo minfo) in D:\a\_work\1\s\src\Compiler\Checking\AttributeChecking.fs:line 403
2022-08-29T10:32:08.1999466Z at FSharp.Compiler.MethodCalls.MethInfoChecks[a](TcGlobals g, ImportMap amap, Boolean isInstance, FSharpOption`1 tyargsOpt, FSharpList`1 objArgs, AccessorDomain ad, Range m, MethInfo minfo) in D:\a\_work\1\s\src\Compiler\Checking\MethodCalls.fs:line 1199
2022-08-29T10:32:08.2003101Z at FSharp.Compiler.CheckExpressions.TcMethodApplication(Boolean isCheckingAttributeCall, TcFileState cenv, TcEnv env, UnscopedTyparEnv tpenv, FSharpOption`1 tyArgsOpt, FSharpList`1 objArgs, Range mMethExpr, Range mItem, String methodName, FSharpOption`1 objTyOpt, AccessorDomain ad, Mutates mut, Boolean isProp, FSharpList`1 calledMethsAndProps, AfterResolution afterResolution, ValUseFlag isSuperInit, FSharpList`1 curriedCallerArgs, OverallTy exprTy, FSharpList`1 delayed) in D:\a\_work\1\s\src\Compiler\Checking\CheckExpressions.fs:line 9661
2022-08-29T10:32:08.2007667Z at FSharp.Compiler.CheckExpressions.TcMethodApplicationThen(TcFileState cenv, TcEnv env, OverallTy overallTy, FSharpOption`1 objTyOpt, UnscopedTyparEnv tpenv, FSharpOption`1 callerTyArgs, FSharpList`1 objArgs, Range m, Range mItem, String methodName, AccessorDomain ad, Mutates mut, Boolean isProp, FSharpList`1 meths, AfterResolution afterResolution, ValUseFlag isSuperInit, FSharpList`1 args, ExprAtomicFlag atomicFlag, FSharpList`1 delayed) in D:\a\_work\1\s\src\Compiler\Checking\CheckExpressions.fs:line 9169
and there's little clue online about what the error means.
I think I'll upgrade my laptop to the latest visual studio and see if it breaks!
(there are lots of variables here, I may boil this down to a much simpler project without thousands of types to see if i can isolate it, but at the moment I'm just looking for quick fixes/some educated guess as to what the cause is)
There is a similar issue reported on the compiler
https://github.com/dotnet/fsharp/issues/13525
that effects C# extension methods.
which is allegedly fixed (though which release I'm not sure), and in an associated issue there seems to be mention of dotnetcore 6.0.400, which both my laptop and my devops build are using.
I got the same problem. It seems that something got changed in dotnet 6.0.7 or 6.0.8 that broke it. Downgrading to 6.0.6 fixes problem for me.
I updated my laptop and
dotnetcore 6.0.400 + visual studio 17.3.2 (i.e. MSBuild version 17.3.1+2badb37d1 for .NET Framework)
does break in the same way.
I may downgrade either my dotnet sdk or my visual studio
I've logged it on the compiler github, allegedly its fixed in my case when vs is upgraded to 17.3.4.
It also allegedly doesnt effect sdk builds on 6.0.302, but fake will use the vs msbuild in preference to the dsk build.
I am struggling to make an Android App, but it always seems to end in this particular failure:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets: Error: Exception while loading assemblies: Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA0009: Error while loading assembly: bin/Debug/(projectname).dll ---> System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
at Mono.Cecil.PE.ImageReader.ReadImage () [0x0002d] in <1b827dd2cbec4ef6829dffcefdcd3b01>:0
at Mono.Cecil.PE.ImageReader.ReadImage (Mono.Disposable1[T] stream, System.String file_name) [0x0000a] in <1b827dd2cbec4ef6829dffcefdcd3b01>:0
at Mono.Cecil.ModuleDefinition.ReadModule (Mono.Disposable1[T] stream, System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00007] in <1b827dd2cbec4ef6829dffcefdcd3b01>:0
at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00073] in <1b827dd2cbec4ef6829dffcefdcd3b01>:0
--- End of inner exception stack trace ---
at Java.Interop.Tools.Diagnostics.Diagnostic.Error (System.Int32 code, System.Exception innerException, System.String message, System.Object[] args) [0x0000a] in :0
at Java.Interop.Tools.Cecil.DirectoryAssemblyResolver.Load (System.String fileName) [0x00045] in <9ca47d05131d4b8c85910dacd818f0c6>:0
at Xamarin.Android.Tasks.ResolveAssemblies.Execute (Java.Interop.Tools.Cecil.DirectoryAssemblyResolver resolver) [0x00123] in <3f37ea95794e430e91f10accab4cf241>:0 ((projectname))
I am wondering what on earth might be causing the error, as I have tried multiple solutions to avoid the error and it often turns up in such random ways.
Last time I got the error it occurred as follows:
I had a project with only two Activity-files and two Layout files.
I created a gridview in the other layout and tested it on the Android emulator -> all was working well.
I resized the gridview and tested the app with the emulator -> error mentioned above occurred.
I deleted the solution, restored a manual backup saved in an other location, and tested it -> it was working.
I repeated the procedure with the gridview -> error occurred.
Now, as I deleted the project and tried to restore the backup again, even the backup did not work anymore. I tried to build it, then clean it and build but every attempt to build it resulted now as an error.
I seem to get mystic errors from time to time ( like Emulator image stopped working after all I did was just add a button with the designer) but every time troubleshooting eventually comes down to this error and I have to scrap the project. I have been working with Xamarin now 18 hours this weekend and 4 hours have been coding and the rest trying to fix the never-ending errors.
I am using MacBook Pro and have tried running the solution from the default directory and external drive.
So in a nutshell: What causes the error mentioned above and can it be fixed or at least avoided?
I tried to google ( long and hard) but could not find a solution that would be of any help.
Ps. Sorry if the post was not correct, it is my first. Would not have posted in the first place but I am desperate.
Thank you for your patience to read all the way to here.
While running one piece of code using Alea.cuBase I am getting a type initialization exception
let worker = Engine.workers.DefaultWorker
System.TypeInitializationException was unhandled
Message: The type initializer for 'Worker' threw an exception.
I am using
visual studio 2012
.Net frame work 4.0
F# 3.1
Another piece of code I tried and got the same error at,
useprogram = template |> Compiler.loadWorker.Default
I started with trial version of Alea.cuBase 1.3.914.
Guide me how to fix this..
Problem got resolved.
My pc was having graphics card quadro fx 1800.
Because Alea cuBase support fermi or higher architecture.
When I tried with k4000 I could run the same program.
I'm trying to run this Self Hosting example, using latest ServiceStack release (4.0.3) and latest Mono/F# (3.2.5).
It fails with an exception on appHost.Init():
{ System.IO.FileNotFoundException: Virtual file not found File name: '<>.FSharpSignatureData.'
at ServiceStack.VirtualPath.ResourceVirtualDirectory.CreateVirtualFile (System.String resourceName) [0x00033] in <>/ServiceStack/VirtualPath/ResourceVirtualDirectory.cs:99 } System.IO.FileNotFoundException
The same does not happen with the C# sample.
Apparently, it looks for some files added as resources in F# assemblies but not mapped to a physical file.
F# does some 'meta data caching' that puts resources (FSharpSignatureData, FSharpOptimizationData) into the assembly. This causes issues when ServiceStack sets up its virtual file system since it wants to map these resources to actual files (I think).
You can get past this by adding the flag --nointerfacedata to the build/compile steps. (in VS Properties > Build > 'Other flags')
I've been meaning to post this to the GitHub issues page.
Under windows, this F# code will extend a file from say 12 bytes out to 655346 bytes when the capacity argument (last argument) is set to a larger size than the underlying file. This seems to be the cleanest way to extend a memory mapped file. Under mono / linux it throws an ArgumentException: capacity unless the file is as long as the mapped capacity. Is there a clean way to get mono to extend the file or do I have to preextend the file before I can map?
let Main () =
let path = "parts.pash"
let l = 65536L
let mm = MemoryMappedFiles.MemoryMappedFile.CreateFromFile(path,FileMode.OpenOrCreate,"pashmap",l)
()
Main()
Error message
Unhandled Exception: System.ArgumentException: capacity at
System.IO.MemoryMappedFiles.MemoryMappedFile.CreateFromFile
(System.String path, FileMode mode, System.String mapName, Int64
capacity, MemoryMappedFileAccess access) [0x00000] in :0 at
System.IO.MemoryMappedFiles.MemoryMappedFile.CreateFromFile
(System.String path, FileMode mode, System.String mapName, Int64
capacity) [0x00000] in :0 at Program.Main ()
[0x00000] in :0 at
.$Program.main# () [0x00000] in :0
Version of mono:
[daz#clowder pash]$ mono --version
Mono JIT compiler version 2.10.1 (tarball Mon Apr 4 10:40:52 PDT 2011)
Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: x86
Disabled: none
Misc: softdebug
LLVM: supported, not enabled.
GC: Included Boehm (with typed GC and Parallel Mark)
EDIT: it appears that the different underlying behaviour of memory mapping is exposed in the API so you need to extend the file yourself to the right length to be platform neutral
let f = File.Open(path,FileMode.Append,FileAccess.Write)
let pad = l- FileInfo(path).Length
let padding = Array.create (int32 pad) 0uy
f.Write(padding,0,int pad)
f.Close()
Looking at the .NET implementation of CreateFromFile there is no implementation of that functionality. Other than argument checking, it is a slim wrapper around the Windows API call from what I can tell.
For this reason the ability to create a larger file is more of a happy coincidence from the .NET land, so it is no surprise that Mono removed that ability if the underlying operating system does not allow similar functionality.
Put more simply, not likely, since the .NET version doesn't technically extend the file either, the Windows API does.
Rather than allocating a potentially large array, and then writing it, it's probably more efficient to seek. I'm not sure of the F# code, but in C# you'd do something like:
filestream.Seek(length - 1, SeekOrigin.Begin);
filestream.WriteByte(0);
With Mono 2.10.8 on Mac OS X seeking by itself was not sufficient, I had to write at least one byte, despite the MSDN documentation for FileStream.Seek saying that it will extend the file.
It seems like Mono could do something similar in their MemoryMappedFile implementation to make it more compatible with .Net on Windows.