Create a build of Bun that doesn’t need AVX2 instructions

[Jarred-Sumner]

This can be feature detected in the install script

It’s really stupid for people to be unable to use Bun on older computers

[qnxdev]

What next?

[zekefeu]

For the time being, I've made a script to simplify and automate SDE's installation based on @renhiyama 's solution, lmk if there's anything to fix.

$ curl https://gist.githubusercontent.com/fuka-g/afb29296db34d2451cdddcc14dbeef3c/raw/0c9e5d43910cf53b9bd82b358559bb8b75ebbfdc/bun-sde-fix-install_script.sh | bash

EDIT: Updated script, this one is up to date.

[guest271314]

@fuka-g I followed those instructions. Now how do I run bun? Nothing chnaged on Linux 5.4.0-42-lowlatency x64.

[zekefeu]

@fuka-g I followed those instructions. Now how do I run bun? Nothing chnaged on Linux 5.4.0-42-lowlatency x64.

Did you restart your shell ?

[guest271314]

No. I am running a live system from RAM.

I can download the Node.js executable node and QuickJS executable qjs and run a JavaScript runtime out of the box.

This makes no sense to build an executable that throws by default.

[zekefeu]

No. I am running a live system from RAM.

I can download the Node.js executable node and QuickJS executable qjs and run a JavaScript runtime out of the box.

This makes no sense to build an executable that throws by default.

Reload the terminal, not the OS

[guest271314]

I did. Same result.

$ curl https://gist.githubusercontent.com/fuka-g/afb29296db34d2451cdddcc14dbeef3c/raw/4ad55d9bef57b8ff3d40eb797c9e9e595e2d04e1/bun-sde-fix-install_script.sh | bash

$ ./test.js
Illegal instruction (core dumped)

I shouldn't be fighting just to run a JavaScript runtime that is 75.4MB. QuickJS executable is 915.5KB and runs out of the box.

[zekefeu]

$ ./test.js
Illegal instruction (core dumped)

$ bun run test.js ?

[guest271314]

$ ./bun run test.js
Illegal instruction (core dumped)

Do I need to do something with the external script bun-sde-fix-install_script.sh?

[renhiyama]

@guest271314 restart your terminal and then try again, should be working

[renhiyama]

also you should be running bun and not ./bun

[guest271314]

@guest271314 restart your terminal and then try again, should be working

I have done that twice now. Same result

$ ./bun --help
	    --use <STR>Illegal instruction (core dumped)

$ ./bun --use
	    --use <STR>Illegal instruction (core dumped)

also you should be running bun and not ./bun

That does not make any difference. I am calling the executable with /usr/bin/env from the same working directory.

It should not this complicated just to run a basic command.

And these implementation details should be in the REDAME.md.

[guest271314]

This is test.js

#!/usr/bin/env -S ./bun 
console.log('Hello, World!');

[renhiyama]

and thats not gonna work for you...

[zekefeu]

This is test.js

#!/usr/bin/env -S ./bun 
console.log('Hello, World!');

You're still using the original bun executable.

The script does not patch bun, but uses SDE as a middleman to handle the avx2 set.

You have to run bun run test.js, which will be an alias for sde -- bun, and not ./test.js, which will use the original bun.

[Nugine]

Hi. Rust can check CPU features and whether the OS supports them.
Is it fine to use rust for feature detection and link a rust static lib into bun?
See https://doc.rust-lang.org/stable/std/arch/macro.is_x86_feature_detected.html

[guest271314]

and thats not gonna work for you...

Evidently. That is why I filed https://github.com/Jarred-Sumner/bun/issues/504.

Cf. QuickJS and Node.js, respectively

#!/usr/bin/env -S ./qjs
console.log('Hello, World!');

$ ./test.js
Hello, World!

#!/usr/bin/env -S ./node
console.log('Hello, World!');

$ ./test.js
Hello, World!

[zekefeu]

Hi. Rust can check CPU features and whether the OS supports them. Is it fine to use rust for feature detection and link a rust static lib into bun? See https://doc.rust-lang.org/stable/std/arch/macro.is_x86_feature_detected.html

AFAIK the issue is that we don't support devices without AVX2 at all yet, not that we can't tell if they support that instruction set or not.

[guest271314]

This is test.js

#!/usr/bin/env -S ./bun 
console.log('Hello, World!');

You're still using the original bun executable.

The script does not patch bun, but uses SDE as a middleman to handle the avx2 set.

You have to run bun run test.js, which will be an alias for sde -- bun, and not ./test.js, which will use the original bun.

More unecessary complications not documented in README.md and that does not work:

$ bun run test.js
bash: /home/user/.sde/sde: No such file or directory

[guest271314]

Hi. Rust can check CPU features and whether the OS supports them. Is it fine to use rust for feature detection and link a rust static lib into bun? See https://doc.rust-lang.org/stable/std/arch/macro.is_x86_feature_detected.html

AFAIK the issue is that we don't support devices without AVX2 at all yet, not that we can't tell if they support that instruction set or not.

Then that exact language needs to be in bold at the top of the README.md.

This is insane.

[Nugine]

Hi. Rust can check CPU features and whether the OS supports them. Is it fine to use rust for feature detection and link a rust static lib into bun? See https://doc.rust-lang.org/stable/std/arch/macro.is_x86_feature_detected.html

AFAIK the issue is that we don't support devices without AVX2 at all yet, not that we can't tell if they support that instruction set or not.

We usually check whether the environment has AVX2 and run fallback functions instead of SIMD functions. I think it's the right way to support old devices.

if (is_avx2_enabled()) {
    return call_avx2_fn();
}
return call_fallback_fn();

[zekefeu]

More unecessary complications not documented in README.md and that does not work:

Because it's a pretty new bug, and should not be documented because it should not be a problem in the first place.

Can you send the output of ls -a ~/.sde ? It should output

.   ia32     Licenses  pinkit      sde    sde64.sig  xed    xed64.sig
..  intel64  misc      README.txt  sde64  sde.sig    xed64  xed.sig

If not, the installation is faulty somehow, which would be either an issue with curl or tar.

[guest271314]

I followed the instructions. The download was successful

$ ls -a ~/.sde
.   Licenses    ia32     misc    sde      sde64      xed      xed64
..  README.txt  intel64  pinkit  sde.sig  sde64.sig  xed.sig  xed64.sig

You folks need to conspicuously document the limitations and restrictions on usage. At the top of your README.md. That is very reasonable and responsible maintenance.

[guest271314]

Note, I didn't install bun executable globally, just as I didn't install QuickJS or Node.js executables globally.

QuickJS I just run using /usr/bin/env.

For node executable (and Deno) I do the same thing, then truncate the executable to 0 because I am not carrying around a 70MB+ executable.

In any event, you need to conspicuously document the limitations and resrictions and dependencies necessary to use bun. Else you are hiding your flaws, in plain sight, no less.

[guest271314]

Is the Intel download expected to be applicable for an AMD CPU?

[zekefeu]

In any event, you need to conspicuously document the limitations and resrictions and dependencies necessary to use bun. Else you are hiding your flaws, in plain sight, no less.

I imagine you read the top of the README carefully and noticed this line: bun is experimental software. That means that, bun still being in beta, there can be (and you are to expect) issues that are not discovered yet, not documented and/or not patched yet. You can't expect bun to be as stable as node. Doc updates needs someone to fork the repo, commit changes, create a PR and wait for it to be reviewed and merged, so this takes time. Bun is relatively new and the v0.1.0 has been released 4 days ago.

Is the Intel download expected to be applicable for an AMD CPU?

No. At least not officially.

That might be the problem. Look up if there is an emulator for AMD CPUs. If so, you can apply the same workaround. I won't be of any help since all my computers are running on Intel CPUs.

[zekefeu]

This issue is cause by an instruction set that is not present on older CPUs. I believe that the contributors are all running on modern CPUs, so they didn't run into this issue before the release of v.0.1.0.

[evanwashere]

This issue was created for tracking progress
You can use troubleshooting instructions to emulate avx2 using Intel SDE, if you encounter any issues please use discussions or join our discord for support

[xHyroM]

Done, see latest release *-baseline builds.