91–100 of 152 posts
i wanted to compute perlin noise to make planet textures fast enough thay the user would not have to experience a loading screen when flying into a solar system. i could not make that happen in c# which the bulk of the game was in. c++ allowed me to compute it around 11 times quicker via SIMD intrinsics.
I am an amateur developer, mostly using python. I had from time to time to code a front-end in JS and it was a huge pain in the bottom (again, I am a real amateur). This until I discovered Vue.js which changed my life. This and lodash made me actually like JS and front-end programming. So this is an example what a framework did not help to improve code but actually made me choose in something else than the language I…
Would you be able to recommend any Vue tutorials/resources/projects you found useful while learning?
nuxt a framework/static site generator build on top of vue (inspired by next.js for react). its conventions are easy to pick up. I find nuxt eliminates all the boilerplate and middleware I would normally have to write for a vue app with SSR (especially since vue-cli really only has a good client-side template). it's a joy to work with.
Well I'll provide a somewhat different story where the lack of change has caused quite a loss in productivity. At my current employer's a big part of the codebase is in Perl and the boss is a fan of the language, so we keep using it. The problem is, Perl is pretty much dead, and most of the packages out there on CPAN feel like they've been built 10 years ago. Not to mention, the language itself lacks what I would cal…
The problem of old languages like perl and Ada is not lack of libraries, but lack of good developers that know how to write idiomatic code. Performing caching at the application level is so trivial in Perl that I do not see how a caching at ORM level could give any benefit.
I don't know anything about the Python libraries as such but if they implement pluggable modules like memcache, redis, SysV SHM, etc., for the caching, then you can chop and change as required without having to make any application level changes[1]. Which is also handy for testing because you can supply your own mock cache module to do ... whatever.
[1] A good example would be going from "direct DB access" to "global memcache" to "local memcache backed by global memcache" - all without application changes.
Earlier quoted context omitted.
Out of interest, to what degree do you think the improvement in comprehensibility is from the new ecosystem vs performing a rewrite with learnings from the original write?
In the first case, we inherited the codebase. However, it was clear that too much attention was paid to low level stuff such as threading, etc. Ruby allowed us to more easily focus on the problem with more of a micro services approach. The Java monolith we replaced was emblematic of its time. Frameworks piled on libraries piled on other things. A lot of complexity to achieve the intended function. The move to golang…
Earlier quoted context omitted.
Like what?
Julia, C++ with libraries, Python with Cython or Numba, etc. You could also get much faster if most of your work is matrix multiplication if you make use of libraries like ViennaCL and a modern C++ compiler.
https://docs.scipy.org/doc/numpy-1.10.1/user/install.html
"To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules use FORTRAN 77 libraries, so you’ll also need a FORTRAN 77 compiler installed."
Earlier quoted context omitted.
Actually that particular C++ was very well written. It had been written by a single very disciplined person over 3 years, following a lot of very strict conventions. So, no it was not really messy in there. But it was big and memory leaks are hard to find. The main problem is that there was some low level funky stuff happening that we didn't have a good grip on. The guy who wrote it thought it would be great to optim…
> The guy who wrote it thought it would be great to optimize the code in some ways, but clearly overdid it. But then I suppose a rewrite would undo those optimizations and solve the problems.
Our team is mostly made of mathematicians and business-focused engineers, so for us C++ was somewhat inappropriate.
My point is trading a little bit of performance for a lot of clarity and safety was a good move.
Earlier quoted context omitted.
Julia, C++ with libraries, Python with Cython or Numba, etc. You could also get much faster if most of your work is matrix multiplication if you make use of libraries like ViennaCL and a modern C++ compiler.
Both Julia and Python use Fortran code under the hood to speed up matrix multiplication. Julia comes with OpenBLAS which is partially written in Fortran, and the following page of SciPy documentation indicates that a Fortran compiler is required for some NumPy modules: https://docs.scipy.org/doc/numpy-1.10.1/user/install.html "To build any extension modules for Python, you’ll need a C compiler. Various NumPy modules…
Earlier quoted context omitted.
Like what?
Julia, C++ with libraries, Python with Cython or Numba, etc. You could also get much faster if most of your work is matrix multiplication if you make use of libraries like ViennaCL and a modern C++ compiler.
Don't know if C++ can ever be as fast as Fortran because all fortran compilers are optimized for the architecture on which they run. (Best fortran compiler for intel cpus is by intel). As for ViennaCL I don't know much about GPU programming and its performance. Never done it. (My only exp is with Cython and Scipy stuff)
A few years ago, I rewrote an `R` script into Fortran, for better than order-of-magnitude speed increase. The script optimized the placement of samplers in a building, in order to maximize the probability of detecting airborne pollutants, or to minimize the expected time required to detect. The rewrite cut the runtime down from 2-3 days to sub-hour. Some of the speedup was intrinsic to the interpreted/compiled divide…
Fortran is an excellent language. I enjoy the fact that people think it's too old and/or difficult to learn, because neither of those are true. It's a great fit especially when the problem domain is heavily numerical in nature.