adw632

adw632

It’s obvious you’re quite a bright person and have invested significantly in developing tria.

I think diversity with compiler implementations is a healthy thing, there are always lessons to be learned and different perspectives that can yield improvement.

But the statement “just use tria” was a bit naive in my view.

Just look at the the long road to implementing erlangs JIT to where we finally have something viable.

Maybe tria may discover some fertile ground and lead to improved performance, we can only hope.

However “just” jumping to another compiler is not going to be viable for most, until tria reaches battle tested status.

Until then, may be you can identify some selective use cases where tria may prove useful, eg as a set of processing nodes in a cluster where the benefit of tria performance can be realised for some safe subset of the code base.

e.g. does tria work with Nx? would tria be compelling for a numerical compute node? If not, then what is the compelling use case for tria?

Getting actual adoption for some concrete use cases would provide important lessons and feedback until fully semantic Elixir/Erlang compatibility is achieved in tria.

I think clearly communicating and being honest about where the rough edges are is essential.

My sense is you have rubbed the community the wrong way, claiming tria is a drop in replacement for elixir which solves everything when it actually doesn’t RIGHT NOW.

Also think about how could one integrate with say one or more tria nodes in their cluster? This might help with both getting real-world use and ultimately adoption until fully battle tested elixir compatibility is realised.

The benefit of even considering tria needs to warrant the additional risk and complexity and that’s always the challenge.

I don’t think there is a single person in the Elixir community who is convinced, other than you, the author.

You need to change that by being real.

I currently don’t see a compelling reason for tria other than my own intellectual curiosity, but ultimately already have it relegated as an “incomplete elixir implementation by a wannabe who agitates the community.”

I’m saying what most are thinking, but beyond that I actually do think you’re very smart and capable so hopefully you take my suggestion and feedback the right way so that your contributions are constructive and lead to improving the state of elixir in ways we can’t predict.

If you do expect the community to take you seriously and to have any chance of competing against the status quo of Elixir on the BEAM you need to be cooperative rather than antogonistic and identify the compelling use case that tria fills.

Could any of it be incorporated into the BEAM or elixir proper?

Can others even work with you?

Elixir thrives because Jose both leads and works with others towards outcomes that benefit the community. I am sure if collaboration was possible it would have already happened.

However if tria js just an academic excercise in compiler writing to be able to say “FIGJAM” then please ignore my post while the rest of the elixir community continue to ignore you and tria.

2
Post #11
hst337

hst337 OP

Yes, it does

That’s true, and that’s why I am talking about the project whenever it is possible: to find someone who wants to try it out locally, not in production, but just in personal setup.

Where did I say that Tria is suitable for usage right now? I didn’t say that. But Tria will be a drop-in replacement. It is almost one already. There is no unsolved problem, except stracktrace formatting, but there are a lot of bugs, which can caught only during the testing. When I wrote “Just use Tria”, it was merely advertising, and I’ve explained what I meant in the next post.

Compiler is completely irrelevant to these kinds of problems. Using Tria or Erlang, or Elixir or Gleam won’t change anything in the BEAM cluster.

That’s true, and that’s what’s written on the top of the README of the project.

Performance. The main goal of Tria is performance. Write some Enum pipes, use some dots, run some benchmarks and see the impact yourself.

Where did I say anything antagonistic? I am always cooperative, and I am open for constructive feedback about compiler’s features and I am open to contributions. To be honest, I value your attention and feedback, but I don’t see anything constructive in it. Perhaps you could give compiler a try, perhaps you could read it’s code, analyze it’s approaches and then improve it with some useful criticism about technical implementation.

Yes, absolutely. I’ve even found some bugs in Elixir during development of the compiler

Yes, I’ve even invited several people personally. I sent mails to people who were doing projects in the same area, we’ve shared ideas, tried to collaborate on some features. You can find a topic with collaboration invite somewhere on this forum.

I am not from academia, nor this project is academic. Tria is aiming to be production-ready with an engineering set of goals. Tria is about bringing existing optimizing compilers’ features to the language, it is not a project about researching new ones.

Why is that? And why are sure that collaboration is impossible?

My overall expression about your post is that you don’t know anything about the project and that you made several wrong assumptions while reading my posts. If you’re really interested in writing performant code in Elixir, you should try reading Tria source, you should try running Tria with TRIA_DEBUG=all env variable to take a look at generated code inside the created tria_generated_context.ex file. It is really interesing.

You can try to take a look at constant folding, at map.field optimizations, at Enum pipes, at inlining, at exception recreation, and so on.

1
Post #12
josevalim

josevalim

Creator of Elixir

That’s inaccurate. We actually compile to:

case map do
  %{^key => value} -> value
  ...
end

So the most common case comes first and the fact map.key is equivalent to remove.function() does not slow down its lookup (except in the cases the key is missing, which raises an exception anyway).

Also inaccurate. We do emit warnings in several occasions, for example:

warning: incompatible types:

    map() !~ atom()

in expression:

    # iex:1
    atom.key

where "atom" was given the type atom() in:

    # iex:1
    is_atom(atom)

where "atom" was given the type map() (due to calling var.field) in:

    # iex:1
    atom.key

hint: "var.field" (without parentheses) implies "var" is a map() while "var.fun()" (with parentheses) implies "var" is an atom()

Conflict found at
└─ iex:1: Foo.remote/1

And we have been slowly moving towards emit warnings at runtime but we obviously have to be careful towards that.

In any case, I think this is beyond the point. Those are micro-optimizations and you should write code that is clear. If pattern matching is clearer, then certainly do that. For example, I doubt that the change from map.field to pattern matching will yield any measurable improvement on your application response time.

6
Post #13
adw632

adw632

Thanks for following up to my post with some good information. Much appreciated.

I have not reviewed the full implementation of your compiler but I have found your posts interesting to read, particularly your obversations on performance and how we might go about improving things.

I have seen a few posts that seem to provoke some negative responses from the community, however that may just be my (potentially incorrect) interpretation and reading of how people responded.

2
Post #14
adw632

adw632

I might be mis reading the tone here, but I sense some adversarial personality traits that may make progress less than optimal, but hopefully not impossible.

Of course I could be completely misreading things yet again.

2
Post #15
D4no0

D4no0

I am on the same side with the things said above about shoving the optimizer down the people throats.

It would be nice to see some articles of actually applying it in practice and the real impact on a real project, don’t take me wrong, benchmarks are a good way to measure performance, however for me these are just numbers that mean absolutely nothing, as a lot of times measurements are not made correctly or get influenced by some hardware specific things.

0
Post #16
josevalim

josevalim

Creator of Elixir

Folks, let’s go easy. No one is shoving a compiler down other people’s throats. Perhaps the initial suggestion could have used more disclaimers, but all of the necessary disclaimers are also in the project’s README. :slight_smile:

9
Post #17
hst337

hst337 OP

In this case, clause ordering doesn’t improve the performance. If we take a look at beam, there is type tag lookup and jump based on it’s value.

That’s true, I meant that the both constructs execute the same code.

I agree, but I would also mention that there is no point in losing performance, when it can be improved automatically, without having to rewrite anything

0
Post #18
josevalim

josevalim

Creator of Elixir

Sure, if we can optimize, we should. My point is that we can’t fully optimize this yet, as we need to worry about backwards compatibility. It is much easier to optimize if the assumption is that we can break code.

1
Post #19
hst337

hst337 OP

We can optimize it, I made a research!

In all top-100 of popular elixir opensource projects, the module.function is used only about 10 times. And in all of these 10 times, it is used for an already existing module or behaviour. It is never used for module, which is loaded in runtime without behaviour.

So the approach to improve the code was

  1. Make all module.function calls with parentheses, just for verbosity.
  2. Use Tria, which would take a look at existing functions and behaviours, and then would decide whether map.field construct can actually be a function call.

And this improved the performance of dot in almost every case possible, since behaviours and functions without arguments, but with generic names are not common. Though, one of them is function config, which is found pretty often

0
Post #20