61–70 of 86 posts
Followed by a search smallest function which is linear in time optimized to a function using filter/sort which is n*log(n) in time. Impressive indeed.
The second code comparison is supposed to point out that the second version. Unfortunately, still not easy enough to read to avoid bugs caused by javascript's "unique" approach. `findSmallestPositiveValue([2,11])` gives the wrong value for the supposedly better function. > Even if the second function takes twice as long as the first, we are in the realm of nanoseconds. How can you possibly know this? You can make eit…
> websites that have noticeably slow javascript "startup" times. Doesn't that just mean it can take a long time for the browser-application to download all of its scripts? That can certainly take a long time but it depends on 1) The speed of the web-server(s) serving those scripts 2) The speed of the network you are connected to So web-sites taking a long time to execute their JavaScript on your PC in the browser doe…
JavaScript is still really slow compared to compiled languages - C, C++, even Java. That super-simple benchmark even after JIT is still 2-3x as slow as the C version, and more complex code can’t be optimized nearly as well. I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps. You don’t see many web games because the graphics required for games today can’t really…
Well, my problem with the testing process that goes into many programs is that they only test with decent hardware. What about those who do not have the latest, state of the art computer or smartphone?!
I hope someday we can convert python to javascript, or even embed python into web pages. There are too many languages these days, for me at least.
To answer my own question there are 2 active python to js efforts: https://brython.info/static_tutorial/en/index.html https://github.com/qquick/Transcrypt
https://github.com/sagemathinc/JSage/tree/main/packages/jpyt...
Earlier quoted context omitted.
With Java there's some relation to the native code, so if you reach that point you can use something like GraalVM to get better performance. In fact there's quite a lot of people who check that with large apps, for most cases JITs perform better in runtime and AoT performs better on startup. But for huge apps this might flip. But the thing is that Java is pretty close to native. Primitive types, object allocation, th…
I agree that with Java you can get close to native performance if you are careful. (I wrote a MCU emulator that beat its C competitor back in 2005, and that's all low-level hackery). But in practice people write a ton of abstraction in Java and programs are quite trashy (i.e. allocate a lot of intermediate objects that are quickly garbage). The APIs and best practices encourage a lot of overabstraction, IMHO, and tha…
I'd like to add that this argument exists for pretty much all "slow" languages and that "if you're careful" often can mean "throw away all upsides your language provides" [1].
Personally, I find these discussions tiring because the ones arguing such points are usually the kind of person that doggedly clings to the "wrong tool for the job".
For example: Although I see rust as the better alternative in many places, I personally find C++ to still be a better language than Java. That doesn't mean I'll insist that Java has no worth or that every program should be written in lower level languages. Horses for courses.
Why can't we just go the Python way and accept the shortcomings of the languages we hold dear?
[1]: Edit: For GCed languages, this often is "avoid the GC at all costs and essentially write less readable C".
the big problem of js on backend is quite bad profiling of nodejs apps.
function main() { let myNum = 0; for (let i = 0; i I'm a little surprised that turbofan doesn't JIT that into an empty function, given that it has no return value or side effects.
It doesn't eliminate loops, but it almost certainly is an empty loop after the full pipeline of optimizations and scheduling. I'm guessing the C version is unrolled or even completely eliminated, because LLVM will definitely eliminate empty loops.
Earlier quoted context omitted.
Well, why did you choose packages that change quickly and are poorly documented then? There are packages that, OTOH, have up to zero dependencies, and haven't changed in years; if you consider those stale, I guess nobody can help you.
I chose the most basic and common packages I could find (terser and rollup), and the changing, no longer valid command-line options I was talking about were command-line options of the npm package manager.
Stop writing C code like this author does! C is a language for experts and there are lots of things that are wrong here. Especially when writing benchmark code, when you do want the compiler to optimize. > int main() The easiest way to find someone who's inexperienced in C is to find someone who declares a function that takes no arguments with an empty pair of parentheses. In C but not C++ you need to write "void" in…
C11§6.7.6.3p14:
> An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.
That declarator is part of a definition. Even if it were not, the elision of a function's formal parameter list does not matter very much if, like 'main', that function is usually not explicitly called.