Skip to content
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

License #15

Closed
Arkaeriit opened this issue Jan 5, 2022 · 5 comments
Closed

License #15

Arkaeriit opened this issue Jan 5, 2022 · 5 comments

Comments

@Arkaeriit
Copy link
Contributor

Do you want to put a License on this software or is it public domain?

@kyx0r
Copy link
Owner

kyx0r commented Jan 5, 2022

It does have a license it's just not made obvious. Not a big fan of sticking licenses into people's faces like some projects do. If you read the top comment in vi.c the writing is of ISC open source license.

@Arkaeriit
Copy link
Contributor Author

Thank you very much.

@kyx0r
Copy link
Owner

kyx0r commented Jan 7, 2022

By the way @Arkaeriit last commit ironically did not end there. Well I always find something off. Anyway pls update cause regex may have (very rare bug). Apparently while checking all that stuff, I found another performance improvement, placing https://github.com/kyx0r/nextvi/blob/master/regex.c#L387 above the goto label causes the compiler to enable extra set of optimizations removing redundant memory reads. Now it can flow everything through eax register, this cuts down the cost by another ~8-10 million Irefs depending on the hardware. Pretty good.

@kyx0r
Copy link
Owner

kyx0r commented Jan 7, 2022

Though clang is pretty terrible optimizing this code, it does too many memory reloads, it's trying to be too smart. Gcc seems to be a lot more context aware. So yeah wouldn't reccomend clang for best performance. It feels like I've always gotta fight compiler cause it always finds a way to generate some crap, don't know who are those people saying that handmade assembly code is very hard to beat compiler, I look compiler explorer and it's a joke. It's definitely better than 5 years ago, but it might be at the peak of it's evolution now. I think part of the problem stems from grinding the compilers to optimize bad code more than try to optimize better already optimized C code. Like for example it is not smart enough to align some VLAs from int sized down to char* thus removing the need for instructions like "mov ebx, dword ptr [r10 + 4*rdi]" down to "mov ebx, dword ptr [r10+rdi]" which seems like might be better as it saves entire multiplication, should be easier to compute and branch predict. Though in modern hardware that may not always be the case.

@Arkaeriit
Copy link
Contributor Author

Thanks for the update, I will rebase my commits on them. Nice work optimizing the code for performance. Not a lot of peoples do it nowadays.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants