Compile .NET code to hardware
-
Ran across this recently:
GitHub - Lombiq/Hastlayer-SDK: Turning .NET software into FPGA hardware for faster execution and lower power usage.
Turning .NET software into FPGA hardware for faster execution and lower power usage. - Lombiq/Hastlayer-SDK
-
@masonwheeler is there a point to this project?
-
-
@gąska said in Compile .NET code to hardware:
@masonwheeler is there a point to this project?
Did you read the onebox?
-
@boomzilla I didn't. But since you mentioned it, I visited the site. Now I wish I could unvisit it.
-
@gąska Well, who wouldn't want to turn their code into female professional golfers?
-
This reminds me of the time I found a library that turned Linq into CUDA (or was it OpenCL?) operations.
I want to play with it SO BAD but I know damn well it'll disappoint me.
-
@boomzilla said in Compile .NET code to hardware:
@gąska Well, who wouldn't want to turn their code into female professional golfers?
On a different note: If it can be compiled into hardware, shouldn't it be possible to also do ahead-of-time compilation to native code instead of JITing MSIL? Would that be advantageous?
-
-
-
@topspin said in Compile .NET code to hardware:
@boomzilla said in Compile .NET code to hardware:
@gąska Well, who *wouldn't* want to turn their code into female professional golfers?
On a different note: If it can be compiled into hardware, shouldn't it be possible to also do ahead-of-time compilation to native code instead of JITing MSIL? Would that be advantageous?
As pointed out, possible, but more often a disadvantage. Jitting allows the native code to be optimized for the platform and conditions at the time of execution. Doing it earlier than that eliminates those capabilities..
-
Well, code-to-hardware is an actual, well researched concept that would be worth a lot if it ever worked well. And .Net is the best general-purpose virtual machine there is, so it makes sense to target it. So the idea is valid. Can't say anything about the implementation.
Just be thankful it wasn't javascript.
-
@gąska said in Compile .NET code to hardware:
@masonwheeler is there a point to this project?
Aside from the fact that they currently support only a rather low-end FPGA board, my guess would be cryptocoin mining. Instead of buying overpriced GPU cards, buy a bunch of sub-$300 FPGA boards and run
space heatershardware customized especially for mining. And instead of wasting your valuable mining time learning a real HDL like Verilog or VHDL, just write your mining algorithm in C#, JS
, or PHP .
-
@anonymous234 said in Compile .NET code to hardware:
Just be thankful it wasn't javascript.
The readme specifically mentions JS (and PHP!) as being supported.
-
@thecpuwizard said in Compile .NET code to hardware:
As pointed out, possible, but more often a disadvantage. Jitting allows the native code to be optimized for the platform and conditions at the time of execution. Doing it earlier than that eliminates those capabilities..
Not really. Whatever theoretical improvements you might get from this approach are seriously outweighed by two realities:
- You can AOT-compile something once for a platform and specific hardware configuration, and the hardware is unlikely to change after that point. (How often do even people like us replace major hardware components?)
- Because of its just-in-time nature, JIT must necessarily suck as a code generator. Doing the really good optimizations is slow and expensive, and you don't want that eating into your program's runtime, so JITs generally don't bother. An AOT can spend all that time once, and you get good generated code forever. (This is not theoretical; it's why Google switched from the Dalvik JIT-based runtime to the ART pre-compiled system: AOT gave them significantly better performance in speed, startup time, and memory usage.)
-
@masonwheeler said in Compile .NET code to hardware:
Because of its just-in-time nature, JIT must necessarily suck as a code generator.
That depends on your JIT… and your runtime. Other subtleties can easily overwhelm.
-
@masonwheeler I could imagine a JIT compiler doing a fast compilation with little or no optimisation initially, then perform a more optimised compilation in the background for frequently-used functions. Potentially this could even use real branch frequency statistics from the actual run in progress.
-
@timebandit said in Compile .NET code to hardware:
@gąska said in Compile .NET code to hardware:
is there a point to this project?
Yes, the . in .NET
Since many languages can be compiled to MSIL, this project can probably enable you to create circuit logic in your favorite language, instead of just HDLs .
-
@pleegwat said in Compile .NET code to hardware:
@masonwheeler I could imagine a JIT compiler doing a fast compilation with little or no optimisation initially, then perform a more optimised compilation in the background for frequently-used functions. Potentially this could even use real branch frequency statistics from the actual run in progress.
Yes, I can imagine that too. I took part in the discussion that led to this happening. It still requires instrumenting and monitoring your running code, which decreases performance noticeably.
-
@masonwheeler said in Compile .NET code to hardware:
It still requires instrumenting and monitoring your running code
A first cut at that is to assume that all branches that lead to an exception being thrown are unlikely, as that codifies existing good practice that people shouldn't throw exceptions as part of normal execution, and that all loops are likely to be looped around multiple times. It's not a perfect set of heuristics, but it gives good results and can be set up without deep analysis. IOW, actual branch frequency statistics are much less useful than you might naïvely guess…
-
@dkf I wasn't even talking about instrumenting branches, which is a horrifying idea now that you mention it! Just instrumenting functions alone can give a noticeable performance hit. (Depending on how heavily you do it, the weight of that performance hit can be a couple orders of magnitude. I've seen profilers that do that, for example.)
-
@masonwheeler said in Compile .NET code to hardware:
Just instrumenting functions alone can give a noticeable performance hit.
Oh, that. Even just getting a count of the number of times a function is called can get quite expensive if you've got to worry about threads (true in the general case), and that'd just be obtaining the necessary information about which functions are going to need to be optimised. If you don't need thread-safety, your overheads are going to be more subtle (i.e., they'll come from the cost of having to spill more registers to memory because of the instrumentation).
-
@masonwheeler I imagine modern JITs do profiling only for short periods of times, and their heuristics are rather good. And as long as cold paths remain cold, there's no need for readjustment. Also, IIRC the profoling results are stored on local machine and reused for future program runs, and you can even embed data collected during development as a resource in release binary.
-
@gąska said in Compile .NET code to hardware:
and you can even embed data collected during development as a resource in release binary.
...or you could just feed it into the AOT compiler and use that to build the release.
JIT is useful for development, but when it comes to release software, AOT wins every time. A halfway decent AOT compiler will beat the best JIT in the world, for the reasons I mentioned above.
-
@masonwheeler said in Compile .NET code to hardware:
A halfway decent AOT compiler will beat the best JIT in the world, for the reasons I mentioned above.
But that doesn't mean that C++ code (which uses an AOT compiler) will beat C# code (which uses a JIT) at a particular task, even one that takes quite a bit of time and resources.
-
@masonwheeler said in Compile .NET code to hardware:
JIT is useful for development, but when it comes to release software, AOT wins every time.
AOT can't take advantage of special instructions available only on some CPUs of the targeted architecture. You also have to provide separate binary for every target architecture.
-
@gąska said in Compile .NET code to hardware:
AOT can't take advantage of special instructions available only on some CPUs of the targeted architecture.
Why not?
You also have to provide separate binary for every target architecture.
Or just a separate AOT compiler. (Again, like what Android's ART does.)
