You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Const<T> type would necessarily compile to a const, an immediate operand, or something of the sort. Additionally it could have extra bounds on it to make some optimizations possible, altho I'm not sure how those would be done in practice.
It would, for the most part, only exist at compile-time (as in, host/rust compile-time, not JIT compile-time).
And also the host code would specify when things get compiled, rather than doing it whenever the library wants to.
The basic idea is to do the most work of optimizing and stuff at Rust compile-time so that very little work needs to be done at runtime. That is, zero-cost abstractions for your JIT compiler. JITs should be performant and tuneable, and HolyJIT might well be performant (altho I doubt it compares to e.g. V8), but it doesn't look very tuneable as it currently stands. I do not believe the library should handle all the details of the JIT but rather it should be a glorified self-modifying code library (just, without being able to modify yourself while you're running. it should make copies ofc).
The text was updated successfully, but these errors were encountered:
The
Const<T>
type would necessarily compile to a const, an immediate operand, or something of the sort. Additionally it could have extra bounds on it to make some optimizations possible, altho I'm not sure how those would be done in practice.It would, for the most part, only exist at compile-time (as in, host/rust compile-time, not JIT compile-time).
And also the host code would specify when things get compiled, rather than doing it whenever the library wants to.
The basic idea is to do the most work of optimizing and stuff at Rust compile-time so that very little work needs to be done at runtime. That is, zero-cost abstractions for your JIT compiler. JITs should be performant and tuneable, and HolyJIT might well be performant (altho I doubt it compares to e.g. V8), but it doesn't look very tuneable as it currently stands. I do not believe the library should handle all the details of the JIT but rather it should be a glorified self-modifying code library (just, without being able to modify yourself while you're running. it should make copies ofc).
The text was updated successfully, but these errors were encountered: