D4no0

D4no0

My opinion is the following on this: you don’t like it, you don’t use it, simple as that.

Good for you, the last time there was a discussion on this topic, it was clear that you are potentially breaking internal features of VM with your opinionated optimizations.

Yeah that’s what they were also saying about chips not being able to go smaller than 10 nm about 10 years ago, and here we are at 4 nm and this is just the begging, we will find another way to advance, because this is what humans do.

It is also clear that you are from the academic world, there is a big distinction between making software that makes money and writing “optimized” software that saves a few hundred bucks on hosting but costs a lot more to be maintained and developed. I came to elixir because I care about delivering results, while having a battle-tested fault-tolerant VM and a great language, not because I care that dot syntax has a lag of 100ns.

0
Post #11
hst337

hst337 OP

I am not, and I’ve been in opposition to academia for my whole life.

I’d like to discuss it, since I am unaware about features my compiler is breaking. One of my goals from the beginning was 100% compatibility with existing behaviour of runtime, compiler and how people expect language to behave. Even these hard problems as runtime recompilation are under my aim in the moment, and they’re supported, but not completely since it is work in progress. If I am missing something, we can discuss it here, or in a compiler’s thread.

While it can be without this lag. And this is a problem. And it can be fixed. And it is fixed in my compiler. Performance optimizations in Elixir is one of thing I’ve decided to work on, this is not a holywar, and I am not attacking anybody with my posts, I am just sharing my experience about problems and solutions to them.

If you want to argue for the sake of it, without any particular reason, then you can, but please, do not involve me into this.

3
Post #12
mat-hek

mat-hek

Membrane Core Team

Thanks for the benchmark and for your engagement in making Elixir faster @hst337. Keep it up :raised_hands:

I bumped into the considered issue a while ago, when doing flame graph analysis which showed that get_in & friends are taking a lot of time. Replacing them with macro-generated pattern matching reduced the CPU usage by ~10% in our use case. A few similar hot path optimisations gave another 10%.

In some cases these optimisations give real speed up and having them automated would be invaluable.

8
Post #13
hst337

hst337 OP

This is exactly what my other project called Pathex does

2
Post #14
D4no0

D4no0

This is what I kind of understood from the posts on this forum, but once again I never went into much detail about the specifics since this is not interesting for me, I think there was something about runtime modules?

This is great that you want to go the 100% compatible way, and it will be amazing if we got at least a part of performance boost that these privileged languages get nowadays.

This is not for the sake of it, the idea is that you shouldn’t be stopped from using a feature, because currently is inefficient.

This is as you said a compiler implementation problem, and once fixed, everybody will be happy. My thinking is that a developer using a high-level language should not care about internals like these, because they are prone to change (and 100% he will not keep track of these changes and then mislead others on what to use and when) and because it fills the head with unnecessary information, instead of understanding how to write maintainable and readable code.

1
Post #15
— All posts loaded —