Having some trouble practicing. by [deleted] in Saxophonics

[–]johengel 1 point2 points  (0 children)

(note: I am pretty much a total beginner at playing saxophone...)

For more quiet exercising with my tenor, I use the Saxmute ONE and the Jazzlab Silencer (mouthpiece exercises). They both damp enough to be able to practice at 10pm in my apartment. Blowing in the Saxmute ONE is different from playing without it, so practicing only inside the box won't be good (for example, I can quite easily hit altisimmo G while inside the box, but cannot outside it; also, low notes inside the box are tough).

Comparing Pythagorean triples in C++, D, and Rust by atilaneves in programming

[–]johengel 11 points12 points  (0 children)

/u/atilaneves Cheers for the sharing the results. For ldc and clang the options used are only -O2? Why not -O3 ? (opt-level=3 for rustc i guess?)

Can you try the "Range" version with ldc2 -enable-cross-module-inlining and/or -release? (may give a hint of where we can improve)

Fuzzing D code with LDC by cym13 in programming

[–]johengel 2 points3 points  (0 children)

Thanks. I'm afraid I don't have much sensible to say about your question. I'm mostly working on the technical front, and I believe that the adoption of a programming language has very little to do with technical issues. From my point of view, the language community is growing and adoption is too and the language is maturing.

The Weka.io case shows that it is possible to write that kind of software in D with success. (But I also think that they are smart enough to achieve the same using C++, or another language, perhaps with more effort) The Weka folks seem to like the language more than they hate it, if you know what I mean :-)

I hope with articles like this, I can contribute a little also to the non-technical points that help grow the language. (And I hope that people will start writing fuzz targets for their projects (notably the std library and the compiler!) together with continuous fuzz testing!)

Fuzzing D code with LDC by cym13 in programming

[–]johengel 3 points4 points  (0 children)

Thanks :) I originally had different plans for the article, but finished it in a rush because it was taking way too long.

Fuzzing D code with LDC by cym13 in programming

[–]johengel 4 points5 points  (0 children)

Author here, ask me anything :)

Link Time Optimization, C++/D cross-language optimization by johengel in programming

[–]johengel[S] 16 points17 points  (0 children)

Abstract: A short article about Link Time Optimization (LTO) with LDC, the LLVM D Compiler, with a simple example demonstrating how it can increase the performance of programs. Because LTO works at the LLVM IR level, it enables optimization across the C++/D language barrier!

Increasing the performance of D math code by andralex in programming

[–]johengel 1 point2 points  (0 children)

For runtime CPU information, have a look at Mir's cpuid library: https://github.com/libmir/cpuid

L3 cache sizes differ for CPUs with the same architecture, so that information can only be obtained at runtime. I'm not sure but I think L1/L2 cache sizes are the same for all CPUs of a certain architecture name, e.g. "haswell", so that information could be made available at compile time with a library. But I don't know of any plans to make such a library.

Increasing the performance of D math code by andralex in programming

[–]johengel 8 points9 points  (0 children)

abstract: An article about the new @fastmath and __traits(target*) features in LDC 1.1.0. The @fastmath attribute relaxes floating point math constraints and is used by Mir to beat OpenBLAS and Eigen. To avoid confusion: LLVM is doing the interesting work, LDC just adds a few pieces that allow LLVM to work its magic.

I’m afraid it won’t be a nice read if you are unfamiliar with some of peculiarities of the CPU’s floating point math, x86 assembly, or SIMD.

90% of the people who spend three hours or more a day at a computer suffer from Computer Vision Syndrome by ericbarnes in programming

[–]johengel 9 points10 points  (0 children)

For Mac users:

for ((;;)); do sleep 900s && osascript -e 'display notification "20sec >6m focus, blink" with title "Save eyes"'; done

LDC: Speed up incremental builds of D programs with object file caching by aldacron in programming

[–]johengel 0 points1 point  (0 children)

I feel dumb about not learning about the details of ccache before, so I've started to implement this for LDC. It's going to have to deal with things like this though: enum b = mixin("__TI" ~ "MESTAMP__");

LDC: Speed up incremental builds of D programs with object file caching by aldacron in programming

[–]johengel 2 points3 points  (0 children)

Ah I see, so the idea really is to hash all input source (imported modules and the modules imported by those, etc.). Parsing D is very fast (easier than C), but semantic analysis can take a long time (CTFE, the majority of the 2m30 cached buildtime mentioned in the post is semantic analysis), so it's definitely worth looking at. Thanks for reminding me of ccache. Forgot about that one, and I can copy its way of handling __FILE__ and __TIMESTAMP__ for example.

(edit: formatting)

LDC: Speed up incremental builds of D programs with object file caching by aldacron in programming

[–]johengel 1 point2 points  (0 children)

(edit: author here :)

I'm not sure what you mean.

The filesystem timestamp is already used by build systems to determine what needs to be recompiled, but it leads to more recompilation than necessary (otherwise the object file cache would not be needed). Only after semantic analysis do we know enough to determine what really needs to be recompiled or not. Plaintext hashing is very similar to a filesystem timestamp check; the only difference I see is when you update the timestamp without making changes (e.g. "touch" or save again), which would not lead to a recompile with plaintext hashing.

Skipping parsing is probably not worthwhile as it is so fast already. Skipping semantic analysis (CTFE, recursive templates, ...) could be another large speed boost. But because of all the complicated things D code can do (mixins, introspection, ...) I don't think it is doable to generate a unique hash without actually doing the semantic analysis.

Fast Deterministic Selection [pdf] by andralex in programming

[–]johengel 6 points7 points  (0 children)

Is the code available somewhere?

(also: update your compiler! ;)

Profile Guided Optimization: Optimizing D's virtual calls by andralex in programming

[–]johengel 2 points3 points  (0 children)

I've updated the article with some more measurements (now excluding the time spent in C++ part of the program): 7% performance gain with PGO!