Month: September 2018

The next release of Campy, available in the next couple days, focuses on improving stability. In this release, I made over 20 Git commits, fixing problems with the WriteLine() code.

• Structs are passed by reference in methods, but weren’t always treated correctly as such, CIL ldarga.
• The CIL newarr still used Mono.TypeReference.GetElementType() which does not work–it is not the same as casting the type to Mono.ArrayType, then calling ElementType!
• Native code for runtime Array.Resize() was faulty–lingering DNA hangover.
• System.Byte not handled in Campy. Fixed.
• Struct deep copy fixed.
• Adding in implementations for System.Math.
• Fixing System_String_InternalIndexOfAny, and other functions in runtime–lingering DNA hangover.
• Fixing deep copy to CPU of arrays created on GPU.
• Adding lock-free managed object pointer table for runtime.
• Rolling forward with fixed Swigged.cuda and Swigged.llvm for Ubuntu, and upgrading LLVM to official version 7.0.0.
• General code clean up.

Moving forward, there is much work to do.

• I am considering how to best handle upgrading CUDA and LLVM with new releases, and handling older versions. SWIG is not robust enough.
• The builds still need to be automated. I’m not sure how to handle the GPU aspect of this. I’m hoping to get some free time donated by a large hosting company.
• The runtime must be rewritten so that it’s Net Standard 2+ conforming, and free of the native (C/C++) code. This is the big problem with moving forward with an AMDGPU target. Alternately, SPIR might work.
• There should be an AOT compiler tool for compiling any C# directly.
• Retarget the compiler to x86_64, for an alternative of Net Core!

Campy is moving forward. However, it is just one person–me–writing basically an entire CoreRT/Mono/… all by myself, whereas you have a whole army working on each of those Microsoft projects. I can only go so fast. But, trust me. I will get there!

–Ken Domino

After taking a short break to accompany my 93-year-old dad to Japan, and hike Mount Fuji, I’m going to address the build issues for releases. Undoubtedly one reason why some haven’t gotten Campy to work (https://sigma.software/about/media/gp-gpu-computing-c) is that the releases are from my build machine. Yes, I am not naive. I knew this was a problem but hadn’t any money to buy a new cheap machine to do builds. This is finally being corrected with the purchase of new AMD Ryzen hardware and Quadro card.

I have been trying a few things, and unfortunately, Campy crashes and burns in some cases due to CCTOR initialization order. E.g.,

Executing cctor System.Void System.Console::.cctor()
Executing cctor System.Void System.Environment::.cctor()
Executing cctor System.Void System.String::.cctor()
Executing cctor System.Void System.NumberFormatter::.cctor()
Executing cctor System.Void System.Globalization.NumberFormatInfo::.cctor()
Executing cctor System.Void System.NumberFormatter/NumberStore::.cctor()
Executing cctor System.Void System.Globalization.CultureInfo::.cctor()

To check, you can set a compiler option to turn on tracing of the CCTOR calls calling Campy.Utils.Options.Set(“trace-cctors”); right before calling Campy.Parallel.For(). If it doesn’t say “Done with cctors”, you can probably be sure that’s the problem. Anyways, I fixed that problem by reordering the calls. I then found out that despite my best efforts in generics, the compiler messes up on generics (in List.cs). In this code, it creates an array with the wrong element type:

public List(int capacity) {
	if (capacity < 0) {
		throw new ArgumentOutOfRangeException("capacity");
	}
	this.items = new T[capacity];
	this.size = 0;
}

I know the fix, but I just won’t be able to address it for a couple weeks–going on vaca. But, I checked in some code changes that improve on the compiler generated names of methods.

Enjoy. –Ken