bluescarni

> In fact, this made me think that the microkernel approach was essentially a dishonest approach aimed at receiving more dollars for research. I don’t necessarily think these researchers were knowingly dishonest. Perhaps they were simply stupid. Or deluded. I mean this in a very real sense. The dishonesty comes from the intense pressure in the research community at that time to pursue the microkernel topic. In a computer science research lab, you were studying microkernels or you weren’t studying kernels at all. So everyone was pressured into this dishonesty, even the people designing Windows NT.

A pretty accurate description of fads and fashions in academia.

I thought one of Julia's compelling features is the ability drop down to the level of index arithmetics without losing performance (as Python does, once you start writing manual for loops).

If I want to stick with higher-level construct for dealing with "collections of numbers", I can use numpy arrays in Python, the STL in C++, etc.

Do you think Julia's high-level constructs are much better than the competition? E.g., how do they compare with C++20 ranges?

Been wanting to try Julia out for a while, but the 1-based indexing is perennially putting me off. I can't see how I can avoid spending a large chunk of time (and endless frustration) unlearning years of 0-index muscle memory (nor I see why should I, for the sake of adapting to a single language that, at least initially, I will be just toying with).

It was probably a good marketing move on their part, a wink towards the Fortran/Matlab crowd, but it certainly damages the language's appeal for potential converts from C, C++ and Python.

Sorry but I think this is still an apt analogy.

1. "Everybody" knows that unordered sets/maps in C++ must de-facto use chaining due to the requirements imposed by the standard.

2. numpy.array is not part of the Python standard library. It is an extra component you still need to install separately. As someone who deals regularly with novice Python users (often coming from Matlab & the likes), one of the very first points of pain/confusion is the fact that I need to teach/convince them not to use the facilities of the core language to represent "vectors".

I wonder what the reaction would have been if he/she had written a blog post explaining how moving from list to numpy.array for storing numerical data in Python resulted in massive performance benefits. You gotta admit the situation is kinda similar.

What is unfriendly about custom allocators? Note that in this specific case you don't need to write any allocation function, you just have to re-implement the construct() function with something that does not value-initialises if no construction arguments are provided.

What a terrible article.

It starts with the comparison of a general-purpose hash table with specifically-tailored one.

Then it throws in a switch from a comparison-based sort to a radix-based one.

Then, the stunning discovery that std::vector value-initialises its elements (fixable with 3 lines of a custom allocator, if you don't want that behaviour).

In the middle, it preaches about portability while at the same time advocating the use of __builtin functions vs standard functions, and type-punning floats to int and back (undefined behaviour in C++).

And all of this for a 572ms -> 320ms performance improvement?

As a full-time linux user and occasional gamer, I have been using the AMD open drivers since circa 2010. The improvements have been massive, both in stability and performance. Since the availability of steam, I have been doing all my gaming exclusively on linux, logging a probably unhealthy number of hours on various games (Dota, various iterations of Civilization, City Skylines, Stellaris, etc.).

Not to say the situation is perfect by any means, but the difference from 2012/2014 is night and day.

> We started working on the game in 2012

> Issues specific to Linux were almost entirely graphics driver related, and unique to the platform.

So this is essentially a rant about linux graphics drivers circa 2012?

The test results on Phoronix paint a rather different picture (i.e., the 2990WX being consistently and markedly faster than any other tested processor).

My initial gut feeling reading the results on Anandtech is that Window's scheduler may not be able yet to exploit the processor's architecture effectively.

I would not be so sure about the declining importance of GCC.

GCC has caught up a lot with clang in the last few years, from the quality of error messages, to standard compliance, compilation times, tooling, sanitizers, etc.

IME GCC tends to produce faster code in practice, even if clang is often able to out-smart GCC in many areas (e.g., IIRC heap elision was first introduced in clang). GCC has a huge amount of inertia behind it, it's still the only compiler officially supported for compiling the Linux kernel, and, as long as the GCC developers don't stop improving it, it will be difficult for clang to take its role as "default" compiler, at least in Linux environments.

I use them both daily and I am really happy that we have the possibility of freely choosing between two such amazing projects. It would be a step backwards if one of them ended up fading away.

> As a C++ programmer I developed my own pet-coding-patterns and bad behaviours (e.g. make methods or destructors virtual even if not needed, create objects on the heap and manage them through smart pointers even if not needed, add a full set of constructors or copy-operators, even when objects weren’t copied anywhere, and so on)

Yikes.

In his first factorial example, he could've avoided templates altogether with constexpr:

https://godbolt.org/g/ZaoMNa

Or just use a template specialisation:

https://godbolt.org/g/TVkHMd

From your list of "first-choice languages", C++ is conspicuously missing. That seems rather peculiar, as the type of genericity you are praising Julia for has been one of the core concepts of generic programming in C++ since basically the late nineties with the standardization of the STL (and it's become an increasingly emphasized part of the language throughout its evolution in the last 10 years or so, see C++11 and later). The example you mention, numerical integrators using different number types (complex, arbitrary precision, intervals, etc.), is the type of stuff which would seem a perfect fit for a template-based implementation.