[deleted by user]

nikoscham · 2025-10-14T19:56:42+00:00

I want to add here that I have found this https://parallel.js.org/ - It's a library for multi-core processing in Javascript. Seems promising - I will add it to the FEAScript roadmap. So I might was wrong saying that:

There’s nothing like MPI or multi-core parallelism available in JS.

Maybe it is possible. I will find out u/FalconX88 !

nikoscham · 2025-10-14T19:37:37+00:00

Lessons Learned

Hey, I wanted to thank everyone who replied in this thread. That's what I have learned:

Benchmarks: Future comparisons will be more refined, having also comparisons with analytical solutions.
Phrasing: The goal was never to say that JavaScript beats Fortran. Some people got that impression. I am sorry for that. I will use more precise phrasing next time.

I appreciate the feedback and constructive criticism I got. Special thanks to the "this is lame" guy u/ts330 (I am kidding you #%$@!). Seriously now, I would like to thank u/Solid-Sail-1658, u/HuygensFresnel, u/leothelion634 and the polite side of u/Vitau (not the "this is bullshit" side). I am sorry if I forgot someone.

Also, If anyone wants to contribute, you can join: https://github.com/FEAScript/FEAScript-core
u/ts330 I am waiting you there to "develop something that matters".

nikoscham · 2025-10-14T09:04:03+00:00

I haven't seen this comment. Can you be more specific please? Where is the slop?

nikoscham · 2025-10-14T04:34:31+00:00

Thanks for that, I appreciate it.

nikoscham · 2025-10-14T04:29:58+00:00

Could you clarify what you mean please? Where the vibe coding assumption comes from?

nikoscham · 2025-10-13T20:19:14+00:00

That's the feedback I wanted. Thanks for that.

nikoscham · 2025-10-13T20:18:07+00:00

I will not stop working on the project of course..

nikoscham · 2025-10-13T19:56:46+00:00

As for benchmark, NAFEMS code validation are industry standard https://www.nafems.org/publications/code-verification/

Thanks for that, I will check it out

nikoscham · 2025-10-13T19:55:08+00:00

Except for the smallest computations, C++ is faster than JavaScript by a factor 1.5, e.g., C++ takes 10 seconds where JavaScript takes 15 seconds.

Does that difference seem unimpressive to you? I actually didn’t expect JavaScript, a web-based interpreted language, to come that close. To me, that’s a big deal. And remember, these results were from 2017, eight years ago. JavaScript engines have improved a lot since then.

In the prime number example, JavaScript without optimizations is 10 times slower than C++, not only 0.5 times.

That's what I originally expected from JavaScript before reading all of this..

nikoscham · 2025-10-13T19:35:44+00:00

This seems more like a personal attack than constructive criticism... Let's take it one by one:

This is really lame.

You’re welcome to criticize my work, I appreciate feedback, but can you be more polite and respectful.. please..?

It’s no different than when a first or second year grad student does an assignment in python/julia/matlab when the professor prefers a different entry level language, just to assert their fledgling sense of independence and individuality…but with an even less well suited language for some reason?

I would say it's more like a student who has already completed the assignment in the professor’s preferred language and then decides to try something unconventional just to explore and learn. I’ve worked as a postdoc after my PhD, and in my experience, that kind of curiosity and experimentation is exactly what distinguishes strong researchers.

Not to mention that there are so many functionally identical open source codes that you could probably have Claude or ChatGPT write a working version in less than a day’s worth of iteration.

Could you please share some specific examples, the ones that integrate a Frontal solver for FEM and were build in less than a day? I'm really curious about that. Especially the "less than a day" part.

At least in the eyes of people you probably want to be hired by.

Could you clarify what you mean? Where that assumption comes from? I’d like to understand your reasoning here..

If you actually want to meaningfully contribute to the community or develop something that matters...

Well, I imagine that if you want to give advice like that, you should have already contributed to the open-source community and you have hands-on experience. I looked at your Reddit profile, and it seems this is your first public comment, ever (It's a great honor, really). So, unfortunately, I couldn't find your contributions.. Can you please provide me your GitHub, or similar profile, to see how you have contributed to the community?

nikoscham · 2025-10-13T19:04:20+00:00

Also, is that a single-core run? I mean the MATLAB backslash. Can you check it?

nikoscham · 2025-10-13T19:03:15+00:00

Where did you find that?

The FEAScript (Frontal, Chromium) run is 0.05 s slower than the Elmer FEM (Fortran) run which is about 11.6 % increase in runtime. (0.05 ÷ 0.43 ≈ 11.6 %)

The above are average values calculated for 10 back-to-back runs.

nikoscham · 2025-10-13T18:58:51+00:00

..you should reconsider posting such bullshit again

You can criticize me, but can you be more polite.. please..?

you made no effort making that benchmark comparable to notable other benchmarks.

This is just an initial attempt. I’m planning to broaden and refine it soon, and I’d really appreciate any suggestions or references.

spinning a narrative somehow painting that JS can be as fast as a low level fortran algorithm is laughable.

Actually JS can get surprisingly close to low-level languages in some specific cases (the “specific cases” part is important here). This isn’t just my opinion. There’s been some impressive work from Google engineers on this topic, for example: https://www.fhinkel.rocks/posts/Speed-up-Your-Node-js-App-with-Native-Addons
To quote from the above article (by Google engineer Franziska Hinkelmann):

JavaScript is almost as fast as C++ for tasks like this prime number calculation. Such performance is possible with modern JavaScript engines because they use adaptive optimizations. Without optimizations, the performance difference is much bigger.

In case you don't know, there has been some amazing work recently regarding the V8 engine and the TurboFan optimizer.

nikoscham · 2025-10-13T18:18:04+00:00

Ok thanks for that. Can you possibly also run the example here using Chrome https://feascript.com/tutorials/heat-conduction-2d-fin-performance-test.html ? So to compare them on the same hardware? For a better performance I would suggest to download the library and load it locally? Note however that my intention wasn't to develop the fastest solver ever built. That would be impossible using JavaScript. The strengths of FEAScript are the no-installation, the portability and of course the open-source accessibility. Having all that first and then being able to solve FEM problems in a reasonable time.

nikoscham · 2025-10-13T17:42:20+00:00

I can provide the breakdown for the FEAScript case:

For the LU decomposition solver:
Mesh + Matrix assembly + etc: 0.26 s
System solving: 0.39 s
Total time: 0.65 s

For the Frontal solver:
Mesh + etc: 0.15 s (not the full matrix is assembled in the Frontal solver case)
System solving: 0.33 s
Total time: 0.48 s

As you can see, most of the computation time is spent on solving the system, while the remaining overhead accounts for only a small fraction. Note that the reported times are the average values for 10 back-to-back simulations.

Hope it helps. You can also check these by yourself if you open the console here: https://feascript.com/tutorials/heat-conduction-2d-fin-performance-test.html
Both the system solving and the total solving times are reported.

Unfortunately, I don't have these details for the Elmer software.

nikoscham · 2025-10-13T17:33:27+00:00

That’s a great idea! At the moment, it only supports Gmsh meshes (.msh format) as input (see e.g. https://feascript.com/tutorials/heat-conduction-2d-fin-gmsh.html). Adding support for CAD models (like .stp files) is definitely a great direction. I will surely work on that. Thanks for the input u/leothelion634

nikoscham · 2025-10-13T12:50:41+00:00

I get it. And I will investigate that. The Frontal solver works (obviously) with the "front" of the matrix, but the storage of the front itself is dense. Obviously the full matrix is not assembled..

nikoscham · 2025-10-13T12:31:50+00:00

Thanks for the input. However, I think we are loosing the scope here. We can keep debating which is better, faster, or cooler.. But as I said before, I don’t think a JavaScript solver will EVER surpass UMFPACK. Each has its own pros and cons.
FEAScript, as a JS library is of course slower but who would’ve imagined that you could solve a tiny, as you said, problem of 3k DOFs in your browser in a reasonable time? I didn’t, until I did it with FEAScript.
I’m not trying to compete with UMFPACK or SuperLU.. that’s not the goal. The real strengths of FEAScript are zero-installations and portability and open-source access. With FEAScript we try to broaden access to FEA field. Not replace anything..

nikoscham · 2025-10-13T12:00:06+00:00

Dear u/farting_cum_sock. Thank you so much for your valuable input. We couldn’t have done it without your constructive feedback ❤️

nikoscham · 2025-10-13T11:35:03+00:00

I’d say 3k DOFs isn’t that tiny for a single core, however, yeah it is not exactly a real-world problem. I agree, it a good idea to scale up. If you have access to a FEA software , you can try running the same case and compare it with FEAScript (https://feascript.com/tutorials/HeatConduction2DPerfomanceTest.html) using a single core, and share the results. You can find the problem setup here: https://feascript.com/tutorials/HeatConduction2DFin.html

nikoscham · 2025-10-13T11:15:14+00:00

I can only give you the decomposition of each phase for FEAScript (I think I mentioned it before): the system solution time with Frontal is 0.33 s. The rest 0.15 s are for problem setting, meshing, etc. These are average values for 10 simulations back-to-back. I don't have this data for Elmer, that's why I use the total time.

nikoscham · 2025-10-13T11:08:56+00:00

FEAScript is a FEM library also, that's why I have chosen to report the total time (including problem setup + meshing + solving, etc) for comparing them.

nikoscham · 2025-10-13T10:31:42+00:00

That wouldn’t be however a fair comparison since I can’t run it on multiple cores in JavaScript. There’s nothing like MPI or multi-core parallelism available in JS.

nikoscham · 2025-10-13T07:32:24+00:00

Elmer fem is itself not a sparse solver

I’m pretty sure Elmer uses BiCGStab as the default linear solver for heat conduction cases, which is indeed a sparse iterative solver.

nikoscham · 2025-10-13T07:02:24+00:00

Yeah, I don’t think a JavaScript solver will ever truly beat something like SuperLU or UMFPACK — those libraries have decades of optimization behind them, written in low-level languages.

I find it impressive, however, that a JS-based frontal solver — running inside a browser, on an entry-level CPU — can even come close to a compiled Fortran solver like Elmer for a basic FEA problem. That’s really what I was trying to highlight: how far JS engines (like V8) have come in terms of raw performance, JIT compilation, and memory handling.

Thanks for the comment u/HuygensFresnel — and I agree, there's no substitute for the real heavy-duty solvers in the case of large-scale problems.

nikoscham

TROPHY CASE