Hacker Newsnew | past | comments | ask | show | jobs | submit | Osiris-Team's commentslogin

This is my idea of a perfect programming language, it's high level and compiles to C. Meaning it tries to give you high level constructs without sacrificing performance.

Let me know what you think!

There is a pretty basic compiler available which I developed 3 years ago that misses almost all features mentioned in the readme, thus you can mostly ignore that, since I want to focus more on the language spec, its recent changes and if its something you would use!


I added some further optimizations and guess I was wrong!


Yeah, feel free to contribute / create a PR with a more C/C++ suited algorithm.


True but let's also not forget the unpredictability of stupidity in human developers which probably cause the majority of performance loss in any language.


Do they compare the second run of Java? Because using GraalVM native image does not really benefit from runtime info and optimization.


Various things.

3,000th run of Java HotSpot.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


I know there was a lot of teeth gnashing in the past about HotSpot warmup, and I think it mostly boiled down to not much of a difference for most tests.



I just now created the repo for this purpose, hoped to reach some more experience C developers with it and prove me wrong.


? Fastest implementation: c_clang with 14.51 ms (0.0145 s).


Yeah I proved myself wrong after adding more compiler optimizations.


Feel free to create a PR on the linked repo and prove me wrong.

To add some detail: I think that 99% of algorithms are faster in Java in their second run than in any other Language due to the better JIT compiler and optimizations that are possible. I am talking about the GraalVM distribution of Java and its latest version, but we might as well use other distros.


As that's what interests you, take a look at JMH with GraalVM like this--

https://sgitario.github.io/graalvm-getting-started/

https://github.com/openjdk/jmh/


1JPM automatically resolves parent and child projects See project.isAutoParentsAndChildren. If true updates current pom, all parent and all child pom.xml files with the respective parent details, adding seamless multi-module/project support.

This expects that the parent pom is always inside the parent directory, otherwise a performant search is not possible since the entire disk would need to be checked.

1JPM helps porting your multi-module project Add JPM.java to your root project directory and add JPM.portChildProjects(); before building. This is going to download and copy the latest JPM.java file into all child projects it can find in this directory, and also run it to generate an initial pom.xml for that child project. The child projects name will be the same as its directory name.

A child project is detected if a src/main/java folder structure exists, and the parent folder of src/ is then used as child project root. Note that a child project is expected to be directly inside a subdirectory of this project.

Now project.isAutoParentsAndChildren will work properly, since all needed pom.xml files should exist.


Yeah I wish I could say build tools are simple. 1JPM was until I had to deal with transitive dependencies. The recursion going on there broke my mind quite a bit.


Running "clean build" should do the trick though, it will delete the ./build directory. Or do you mean the local maven repo?


Neither. The corrupted cache is in the user-level gradle cache directory, which is untouched by `gradle clean`.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: