-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add goals, non-goals, risks #3
Conversation
|
||
2. *Feature detection.* Profiles are directed at ecosystem creators, not users of the language. While it may make sense to provide programmatic means for certain applications to become portable even across incompatible ecosystems, such means are outside the scope of this proposal. | ||
|
||
3. *Alternate semantics.* Profiles can only _restrict_ the language, they are never intended to _change_ it, e.g., by introducing alternative features or alternative behaviours. Language changes would introduce significantly larger complications for ecosystems, implementations, and users. In particular, they would preclude the existence of a "full profile" that includes everything, and targetting which allows implementations to remain profile-agnostic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A subtlety here is that relaxed-math mode is proposed to be framed such that deterministic mode is the prominent mode in the spec, and relaxed mode is an alternate superset of it. In particular, the hope is that by doing so, we can contain the new list nondeterminism behavior within this mode. I wonder if that's feasible within this profiles framework.
I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?
Yes, semantically that would work. Editorially, the list semantics would still have to be part of the main spec, but practically overridden by set determinism, unless that is disabled by a profile.
In general, the main body of the spec has to specify the union of all possible behaviours. So unfortunately, we cannot technically shove out non-determinism there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A subtlety here is that relaxed-math mode is proposed to be framed such that deterministic mode is the prominent mode in the spec, and relaxed mode is an alternate superset of it.
Personally, I have a somewhat strong opinion that we should frame things in terms of a "full/default" profile and a (clearly marked alternative) "deterministic/strict" profile/mode. The safe thing for users to do is to write/compile/produce their program anticipating the non-deterministic semantics, because then moving to a "deterministic/strict" implementation is safe. If we message that the deterministic semantics is the "normal" one, and this bleeds into documentation or tooling, I worry that we'd be creating a hazard for users.
I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?
Given the intended use-cases of qfma
I think even the full profile is going to need list non-determinism.
proposals/profiles/Overview.md
Outdated
|
||
1. *Profile inflation*. As stated above, it is a goal of profiles to _minimise_ fragmentation. For that purpose, the number of specified profiles should be as small as possible – a handful rather than a dozen. While it could be tempting to introduce micro-profiles for all sorts of special purposes, that temptation must be avoided. The goal is coarse not fine granularity. | ||
|
||
2. *Misfeature white-washing.* Blessing the notion of language subsets may reduce the scruples against introducing questionable features into Wasm, because those could be "barred" into a profile. Such an approach would still increase fragmentation as well as aversely affecting the overall complexity budget and reputation of the language. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, could I suggest rephrasing this bullet along the lines of "Process short-cutting. Blessing the notion of language subsets may reduce the perceived need for scrutiny or consensus-building when adding new features. Such an approach would still increase fragmentation as well as adversely affecting the overall complexity budget and reputation of the language."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, reworded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review!
|
||
2. *Feature detection.* Profiles are directed at ecosystem creators, not users of the language. While it may make sense to provide programmatic means for certain applications to become portable even across incompatible ecosystems, such means are outside the scope of this proposal. | ||
|
||
3. *Alternate semantics.* Profiles can only _restrict_ the language, they are never intended to _change_ it, e.g., by introducing alternative features or alternative behaviours. Language changes would introduce significantly larger complications for ecosystems, implementations, and users. In particular, they would preclude the existence of a "full profile" that includes everything, and targetting which allows implementations to remain profile-agnostic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it makes sense to have the "full profile" define the relaxed-simd opcodes with set nondeterminism, and then have relaxed-math mode be a subset which introduces list nondeterminism?
Yes, semantically that would work. Editorially, the list semantics would still have to be part of the main spec, but practically overridden by set determinism, unless that is disabled by a profile.
In general, the main body of the spec has to specify the union of all possible behaviours. So unfortunately, we cannot technically shove out non-determinism there.
proposals/profiles/Overview.md
Outdated
|
||
1. *Profile inflation*. As stated above, it is a goal of profiles to _minimise_ fragmentation. For that purpose, the number of specified profiles should be as small as possible – a handful rather than a dozen. While it could be tempting to introduce micro-profiles for all sorts of special purposes, that temptation must be avoided. The goal is coarse not fine granularity. | ||
|
||
2. *Misfeature white-washing.* Blessing the notion of language subsets may reduce the scruples against introducing questionable features into Wasm, because those could be "barred" into a profile. Such an approach would still increase fragmentation as well as aversely affecting the overall complexity budget and reputation of the language. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, reworded.
|
||
1. *Versioning.* Profiles are _not_ intended to distinguish new vs old versions of the language – that is an independent dimension for which we already have have version numbers. Rather, we fully expect that new versions of the language will extend existing profiles. Profiles are meant to codify _permanent_ use case distinctions, not temporary implementation deviations. | ||
|
||
2. *Feature detection.* Profiles are directed at ecosystem creators, not users of the language. While it may make sense to provide programmatic means for certain applications to become portable even across incompatible ecosystems, such means are outside the scope of this proposal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to give some thought to how the existence of profiles affects users and producers.
Profiles that only support a subset of instructions are only useful if there are producers that offer an option to avoid generating the excluded instructions.
Profiles that subset semantic behaviour like non-determinism may also attract producers to exploit this (e.g. using qfma
as deterministic fma
).
There's also a real difference between the two above. Inadvertently producing code for a syntactic subset is safe, and will still run correctly on "full" implementations. Inadvertently producing code for a profile-blessed semantic subset is hazardous, because it may rely on assumptions that aren't true in "full" implementations.
I think the following should be true (not attached to exact wording):
- There should be a "full" profile, and other profiles may only present subsets of instruction availability and non-deterministic behaviour in comparison to the full profile.
- The intention is that code produced for the full profile should either work correctly, or fail at latest at validation time with "feature not supported" on other profiles.
- Producing code for the "full" profile should always be the default, and alternatives should be clearly messaged.
- Users should especially be protected from inadvertently producing code for a profile that subsets semantic behaviour (i.e. less non-determinism).
- Profiles should always be mutually compatible and composable. No two profiles should subset semantic behaviour in different ways.
- Runtime conditioning on the current profile should be avoided at all costs, both at the language-level, and at the toolchain/platform level. Users should "lock in" to a target profile at produce-time, and know at deploy-time which profile their code will run on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to me, but do you suggest including these points as a goals/risks, or discussing them separately somewhere?
One comment, though:
Inadvertently producing code for a profile-blessed semantic subset is hazardous, because it may rely on assumptions that aren't true in "full" implementations.
[...]
- Users should especially be protected from inadvertently producing code for a profile that subsets semantic behaviour (i.e. less non-determinism).
I'm not sure this problem is qualitatively different from the one we already and inevitably have regarding future extensions. For example, we discussed that code might be assuming to know the subset of all subtypes of, say, eqref, which obviously is a bogus assumption.
How do you suggest detecting and protecting against such misassumptions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there needs to be some explicit acknowledgement of "risks" from a user/producer point of view. For a user - inadvertently producing (for example) "strict" code that they then deploy to the Web. Similarly for a toolchain - confusing users with multiple/hazardous options and dealing with attendant compositionality problems. I think this is somewhat under the "fragmentation" theme but the difference is that the user experience problem is an inherent risk of profiles that we can't mitigate purely through specification language/process (unlike the existing "inflation", "short-cutting", "abuse" risks).
I'm not sure this problem is qualitatively different from the one we already and inevitably have regarding future extensions.
...
How do you suggest detecting and protecting against such misassumptions?
Some of the specifics of my post could be put elsewhere, but do think the design restrictions above should be prominent somewhere. At the very least we should have everyone active in the CG agreeing on them (esp. toolchain people). I agree some of the above is a matter of social responsibility - e.g. having some "only use this if you know what you're doing" documentation around a producer flag for "strict" - but there are some spec principles here - e.g. having a "full" profile and compatibility/intersection between different profiles, ensuring that toolchains always have a sensible "default" to offer users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to turn this into something actionable, as far as this PR goes I'd be happy with just a couple of sentences being added to the "risks" section flagging up user experience issues to do with toolchain use and targetting the wrong profile. My other points can live somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a risk item on "over-optimistic assumptions" (for lack of a better title), and a section on Intended Properties, mostly copying your items above. PTAL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the above I considered less determinism a risk to correctness of the algorithm, while this seems to be motivated by more determinism being a risk of a potential performance degradation?
I think the opposite is more practically likely - targetting a more deterministic environment can create correctness hazards for users who accidentally then use the code in a less deterministic environment. The safe thing is always to target the lowest common denominator ("full").
My mental model is kind of reversed. In my understanding a "lowest common denominator" of all wasm runtimes would imply features that all of them support, which is kind of core Wasm 1.0. In reality over time we're adding features, not taking them away and then use profiles to restrict them for various reasons, so a full profile would be expanding and not be the lowest common denominator for a runtime that does not support SIMD or GC for example.
Consider a user who writes a C++ program using
std::fma
. If they inadvertently compile their code targetting Wasm in the "deterministic" profile, and then deploy it in an environment that implements the "full/relaxed" Wasm, their code will likely break as thefma
will be compiled to relaxed SIMD'srelaxed_madd
, which is the most efficient scheme but only correct if the Wasm environment is "deterministic". Conversely, if they inadvertently compile their code to Wasm in the "full" profile, and then run it in a "deterministic" environment, they may lose some performance becausefma
will be compiled less efficiently, but nothing will semantically break.
I see, I am more coming from the assumption that modules are provided as .wasm binaries from a registry and would not be compiled by consumers. In that case the instruction would already be baked in, so changing the profile in Wasm land would refuse to compile the module as "not compatible with this profile". I see the profiles more living in the Wasm runtime when compiling .wasm modules checking if the module complies with the profile and setting a code path - a view which is outside the scope of this proposal but could be complementary and interesting for feature detection.
I agree if the producer provides a profile it could be "full (speed)" by default (and maybe Wasm version to target for backwards compatibility), but it would have to be explicitly provided, otherwise core Wasm 1.0 assumptions are violated. If not provided, by default compiling a module "without a profile" core Wasm 1.0 should be assumed, not including extensions like SIMD at all. If they do restrict the profile I agree this needs to be documented and configured in their toolchain to avoid setting the wrong flags and maybe a profile check on the produced .wasm module done to verify, but it's hard to standardize beyond general recommendations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thought, not sure if this has been considered yet: I think it would make sense to bake in the profile which a module has been compiled with into the .wasm module into a section, so a case as you described where the producer "messes up" would be detected by the Wasm runtime during compilation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but it would have to be explicitly provided, otherwise core Wasm 1.0 assumptions are violated. If not provided, by default compiling a module "without a profile" core Wasm 1.0 should be assumed, not including extensions like SIMD at all
To some extent this is already a concern that shows up in both JS and Wasm - I brought up the bulk memory example which Binaryen has agonised over (emscripten-core/emscripten#15376). I don't think we should look to profiles as a clean solution to this, as it's essentially a versioning issue. @tlively previously said in the above issue "We previously decided to be somewhat aggressive about updating LLVM defaults (default after phase 4 + 6 months, IIRC)" - I don't know if this is still the case and whether SIMD would ever be enabled by default.
EDIT:
Another thought, not sure if this has been considered yet: I think it would make sense to bake in the profile which a module has been compiled with into the .wasm module into a section, so a case as you described where the producer "messes up" would be detected by the Wasm runtime during compilation.
I need to think more about this! Instinctively I feel that it's preferable not to have a "runtime" check like this, but it may be the lesser evil.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To some extent this is already a concern that shows up in both JS and Wasm - I brought up the bulk memory example which Binaryen has agonised over (emscripten-core/emscripten#15376). I don't think we should look to profiles as a clean solution to this, as it's essentially a versioning issue. @tlively previously said in the above issue "We previously decided to be somewhat aggressive about updating LLVM defaults (default after phase 4 + 6 months, IIRC)" - I don't know if this is still the case and whether SIMD would ever be enabled by default.
With profiles this might be resolved without versioning, you could provide a profile that the compiler understands and adopts their defaults to. As you mentioned "aggressively" implies breaking code since the defaults were updated, which could be solved by a profile with the previous defaults, which the module should ship with to to declare its needs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDIT:
If say in the worst case the module has been produced years ago and is no longer maintained, users will cut their finger using the module in a full profile that now allows non deterministic behavior. I would tend to opt for explicit opt-in of extensions with considerable tradeoffs to initial core wasm e.g. that are a breaking change in semantics like relaxed SIMD introducing new non determinism by not including this in a full profile, so at least someone needs to enable this explicitly.
Relaxed SIMD isn't expected to cause this kind of problem, because the non-determinism is only present in new instructions the proposal is adding. With or without profiles, it will never be the case that we make a proposal to add new non-determinism to existing instructions in a way that affects previously-produced code at rest - this would break Web compat.
We should move the discussion over, but since this is a subtle issue that might be lost by losing context, answering your edit here:
It might not be common, but I would not expect this in general: In a similar scenario to the ones you described flipping a compiler switch or changing toolchain defaults, if the module in an old code base is just recompiled e.g. for fixing a typo, a contributor with a newer compiler supporting a new instruction, with a full profile you might produce a module with instructions not considered, changing the implicit profile of the module. In this case all bets are off if this is no longer matching the implicit contract agreed on between the producer and the consumer.
This touches on how and where a module's interface contract is defined, validated, and guaranteed to be stable, explicitly or implicitly and how we best ensure it is not broken over time. If it is implicit in the source code and the version and flags of the toolchain used, as you have mentioned this is rather subtle and fragile.
I think there is great value in explicitly declaring the assumptions of a module being produced or consumed in a profile shipping with the module and validating against this at the time the module is produced and consumed. It seems to me this is part of the contract between the producer and consumer and in my mind lives closest to the space of WebAssembly Interface Types (WIT) contracts for modules as the implications might affect the long term stability of standardized interfaces, possibly beyond a specific module.
After more-recent discussions of this with folks at the in-person CG, I've started to question whether we need the general-purpose/generic mechanism of "profiles" or whether we should start only a single "deterministic mode". In particular, w.r.t:
|
I think there are many embedded processors which will not support vector instructions and are likely to want to support a profile without SIMD. While I too hope that GC becomes widely supported across engines, I can see a path where some engines don't support GC, but instead support multi-memory, and there is a polyfill. |
I would be happy for the "profiles" proposal to be purely about setting up a conceptual framework for handling profiles (backed by consensus polls but not necessarily a phase advancement process), and then each individual "profile" has to be separately justified by an implementer approaching the group. EDIT: that's effectively our justification for the "deterministic" profile, with @lukewagner and others putting forward a cloud perspective at the in-person meeting. |
What about a future where there are severely constrained profiles for oddball scenarios, e.g. a programmable routing mesh that doesn't allow more than 1 page of memory, no tables, no I sense there is tension between the goals of avoiding ecosystem fragmentation and also broad adoption. I'm not sure we want the CG to be the bottleneck for new, unenvisioned use cases for Wasm popping up that are likely to subset it in unanticipated ways. Or are those just not "profiles"? |
I think it's important for us to be conservative (and to be clear, we hopefully wouldn't say yes to every profile suggestion). Profiles could be thought of as "blessing" a small number of particularly fundamental (and conceptually well-demarcated) use-cases in the core spec, so it's not unreasonable that the CG is a bottleneck. Experimentation can happen independent of this - if someone wants to fork the spec and frame their oddball usecase/restrictions as a "profile" they write themselves, more power to them, but it shouldn't be necessary. |
Strongly agreeing with @conrad-watt that we should be very conservative with profile introduction, and only consider clear-cut and broad use cases, not oddball scenarios. I intentionally list the risk of "profile inflation". ;) |
Agreed with @conrad-watt that it would make sense to introduce the conceptual framework of "profiles" up front but to require each new profile to be voted on independently based on concrete (and I'd add some fuzzy notion of "used at large") implementations approaching the group and making the case for a particular profile. I'm happy to help make the case for the deterministic profile so that we have at least one. But I don't think we should speculatively add the other ones up-front, at least without some more evidence from implementations that they're necessary. And yes, there's nothing stopping an implementation from simply shipping whatever ad hoc subset they want -- the question for the CG is when to bless particular subsets with a "profile", thereby imposing the burden on the broader wasm ecosystem (particularly producer and distribution tooling) to have to worry about this profile and what's their "story" for that profile. |
I think we'll need a more nuanced approach. There is functionality for which it is obvious that certain environments do not have the ability or capacity to implement it: GC, stack switching, threading, SIMD, all come to mind. Nobody is helped if we pretend this reality doesn't exist. We'd just create more fragmentation and tooling issues, not less. And alienate some of our customer base. In particular, we have to ensure that no language extension represents a regression for an existing part of the Wasm customer base. If we, e.g., were to land GC without a profile to opt out of it, then we'd be unhitching some customers from the progression of the language and put them in a limbo state where they're technically no longer able to adopt the effectual version of the standard. We'd be pulling the rug under them, which is not something we should do! Hence, it is actually key to make the consideration of suitable profile integration part of the proposal process. No non-trivial proposal should land that knowingly breaks relevant customers. For the same reason, we need to fix the situation for SIMD asap, since we already do know that we have regressed for some customers. |
I want to push back a little - I think that a necessary (but not sufficient) requirement for a profile to get in the spec should be that at least one implementation is actively planning on restricting itself to that profile and cares about the spec enough to tell us. I worry that a profile for each major spec feature is going to to end up looking very similar to versioning. |
It depends on how we ultimately define profiles. For example, is there an "embedded profile" that becomes a bin that we would major spec features into one-by-one, or are profiles negatively defined, i.e. the "no SIMD profile". Are profiles feature sets that can be mixed and matched? |
I agree general higher-level profiles that group possibly over time expanding sets of features like "embedded" or "performance" would make sense, and then allow to override them, but positively and negatively, say "performance" AND "deterministic" would restrict the "performance" features to deterministic ones, or "embedded" OR "GC" would override the embedded profile only to extend it by this feature. While this is not versioning as it's not linear, it might prove useful to express additional version profiles like "core wasm 1.0" "core wasm 2.0" to include sets of features to make it less verbose to target an evolving standard over time. |
To clarify, I don't mean to imply that every major feature needs an opt-out, but that the potential need for opt-outs ought to be considered for major features. That may well result in no action needed, it may also result in an existing profile being sufficient to cover it (e.g., the deterministic profile for relaxed SIMD). |
I don't think discussing various profiles in the abstract will be too fruitful without some actual embeddings showing up and describing their concrete constraints that prevent them from supporting a feature. Also, I think that's the attitude we should take with core wasm: this should be a collection of features that every implementation would want to support unless they have a hard reason not to. If we don't take that attitude, then I think we'll end up with a bunch of lower-value instructions justified by "you don't have to support it if you don't want to" which would in turn lead to unnecessary fragmentation and break what is currently one of wasm's key value propositions. |
Definitely, I believe what we discussed to be placeholders to illustrate a conceptual framework and general mechanism that could be evaluated empirically, easier to reason than just talking about A and B.
Agreed. That's why I do think a kind of core WASM versioning profile in form of core WASM 1.0,. 2.0 as the default would be a strong signal what implementers should support and put us in a better position than scattered support and feature detection on the web. (With the discussed models a profile 3.0 could also discourage using a feature that is still there in terms of backwards compatibility but has been deprecated but could be overridden by continuing to use an old profile or extending the profile.) |
I do want to point out that the current vision for profiles is explicitly not aiming to solve this problem (as called out here). Honestly mis-managing ecosystem expectations here is enough of a hazard that I've almost talked myself into agreeing with @lukewagner's previous comment. The usecase of profiles in semantically subsetting behaviour is somewhat distinct from the usecase of syntactically subsetting features, and I'm beginning to question the importance of the latter. Producers already have granular flags for enabling/disabling features, and I'm not sure that the user experience of "picking the wrong syntactic profile" is so different from "enabling the wrong feature flags". In both cases the environment will error with "instruction not supported" (and presumably document which flags/profile should be selected in the producer). |
As I recall it, there was a strong sentiment at the time we started discussing GC that we can only add such a thing when it remains optional. |
I thought about the same thing. I concluded I believe it's worth having a profile declaration shipping with the module to validate the compiled module still complies with the requirements to prevent the scenario you described where a compiler flag is switched (or the default of the toolchain changed silently), so it would be good to be able to describe, ship and validate such a profile in the producer's toolchain as an afterstep to compilation so the profile cannot accidentally change and the producer can describe the intended supported scenarios. |
Also, maybe relevant in a broader context, a Wasm profile could be used to declare requirements as consumer constraints in the context where the module is used during compilation from the .wasm module to machine code, it could be a hint to the compiler it can strip out certain alternative but unused/dead code paths or compile the module despite not supporting a certain feature if there is an alternative code path. None of this is needed for an MVP, but it would be good to at least not rule out these options accidentally without discussing them. |
IIRC, much of that sentiment was mine ;-) I think a newer, more-nuanced sentiment (that I've heard shared by a number of folks) is: in adding new features to wasm, we should not force GC on languages that do not fundamentally require GC but want to use the feature (e.g., stack-switching). Thus, the languages that need GC are doing GC in any case (in linear memory or in host memory via wasm-GC) and the languages that don't aren't. |
It's nice of you to take the blame, but that's not what I remember. ;) A significant portion of the room was highly uncomfortable with the idea of adding GC to Wasm, and to force it on every engine. And rightfully so, I should add. To clarify again, I'm not suggesting to design profiles randomly or inflationary. Profiles are meant to address the case where we want to add functionality to Wasm of which we know for a fact that it is impossible to implement in a meaningful manner on some relevant hardware, OS, or other form of platform. When adding such functionality, we have 3 choices:
Maybe I'm missing something, but I have a hard time understanding how (1) or (2) could be more beneficial strategies than (3). From what I can see, they would neither serve the standard nor its users. |
I don't think we fundamentally disagree, given that you're saying the condition for adding a profile is "we know for a fact that it is impossible to implement". The point here isn't to never add profiles, but to only add them based on sufficient evidence and demonstrated significantly-widespread implementations that in fact have the constraints that motivate the profile. I don't think we've seen this for non-GC and non-SIMD yet, but I'd certainly be open to see more evidence. |
Both |
I think we should hear from the folks who actually work on those engines rather than making judgements in the abstract on their behalf. For example, iiuc, the two engines you mentioned are interpreters, so it doesn't really matter what the CPU supports. |
WAMR has a JIT now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM from the pov of the document, but I think the discussion in this thread needs to continue.
proposals/profiles/Overview.md
Outdated
|
||
3. *Abuse.* It may also be tempting to apply the concept of profiles to scenarios it is not intended for, such as versioning. That would harm the purpose and create conflict with stated goals such as durability and minimised fragmentation. | ||
|
||
4. *Over-optimistic assumptions.* Producers may assume that certain invariants that happen to be true for a profile they target hold in general. This may lead to incorrect behaviour of their code when run in more general environments. In general, producers should always assume the presence of the full language, even if they merely target a subset profile. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say "inconsistent" or "mismatched" assumptions here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to "false".
I suggest we continue the discussion on issue #1, which already raised the same question. |
To clarify the scope of profiles.
@conrad-watt, PTAL.