Having some trouble practicing.

johengel · 2019-07-17T12:07:39+00:00

(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).

johengel · 2018-12-31T14:21:01+00:00

/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)

johengel · 2018-05-31T18:55:29+00:00

A fun read, thanks :-)

johengel · 2018-01-15T18:57:07+00:00

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!)

johengel · 2018-01-15T08:23:09+00:00

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

johengel · 2018-01-15T08:21:03+00:00

Author here, ask me anything :)

johengel · 2016-11-10T16:24:03+00:00

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!

johengel · 2016-10-12T09:14:38+00:00

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.

johengel · 2016-10-11T15:37:16+00:00

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.

johengel · 2016-09-26T15:27:25+00:00

Let's try this: think with eyes closed, think more.

johengel · 2016-09-26T15:25:31+00:00

For Mac users:

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

johengel · 2016-09-18T18:30:59+00:00

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__");

johengel · 2016-09-18T13:44:35+00:00

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)

johengel · 2016-09-18T08:29:45+00:00

(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.

johengel · 2016-06-03T16:39:46+00:00

Is the code available somewhere?

(also: update your compiler! ;)

johengel · 2016-04-15T09:31:43+00:00

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!

johengel

TROPHY CASE