This is a very interesting concept and another example of what can be done with Rust. However and without the intention of discouraging the author, I did not find any performance improvement from Alacritty using Ubuntu 16.04 on an i7-4500U (using integrated graphics HD 4400). Here are some numbers, simply printing the contents of 446 files:
At 80x24:
gnome-terminal:
real 0m0.848s
user 0m0.032s
sys 0m0.072s
Alacritty:
real 0m6.832s
user 0m0.032s
sys 0m0.164s
At fullscreen:
gnome-terminal:
real 0m0.819s
user 0m0.020s
sys 0m0.088s
Alacritty:
real 0m8.972s
user 0m0.064s
sys 0m0.164s
The font was a tad smaller by default on Alacritty, changing it made no significant difference in the numbers. Since the difference in performance was quite noticeable I decided not to test other possible configurations, but I could do so if it might help.
My graphics card has a pretty poor performance in general so that might be an indication that, since the performance of Alacritty is directly impacted by the graphics card, it might be useful for the author to determine the "minimum requirements" for Alacritty to outperform the competition.
In any case, it might not be a fair comparison as the author has stated that this is a pre-alpha release, but maybe he can find it helpful in some way, as he suggests he hasn't been able to find a test in which Alacritty didn't perform as well as another terminal.
Really interesting, I wrote a logic puzzle solver in Prolog a long time ago while I was in uni, I just created a repo for anyone who wants to check it out. Unfortunately the documentation and comments are all in Spanish...
One of the most important reasons to use calloc, other than the zeroing of the allocated memory, is the fact that it checks for integer overflows (at least on most implementations).
For example, when allocating an array of n elements, in malloc you would do something like the following:
ptr = malloc(sizeof(int) * n);
Which could potentially lead to an overflow of the size passed to malloc, hence allocating a significantly smaller buffer and end up accessing adjacent memory which hasn't been allocated to the buffer (buffer overflow)
Calloc requires two arguments, one for size and one for number of elements, which allows it to check for an overflow before performing an allocation (e.g. by using SIZE_MAX):
ptr = calloc(n, sizeof(int));
This is not to say that zeroing memory is not useful. There are many situations in which a zero in a memory block represents the end of the usable data, as for example in a string, so zeroing memory in those situations is definitely recommended.
Using calloc instead of malloc, just for checking arithmetic overflow, is superfluous. You can always write a check or a wrapper for malloc that does that automatically. It is so easy I can write it here:
_Bool Check( const size_t a , const size_t b )
{
if( a > SIZE_MAX / b )
{
return false;
}
return true;
}
(If proper warnings are enabled, it also provides extra integer type checking.)
There is no reinventing going on here. In C you have to write relatively low level code. This includes manually calling allocs for objects, which includes the code for checking your arithmetic. At some point you will have to write that code. If you are smart you will wrap it into a function.
I don't see the point of the discussion, that piece of code (or relatively equivalent), is already being performed by a libC function (calloc, in this case), how is that less convenient than you writing it yourself?
It has nothing to do with how smart you are or how low level C is, you are effectively reinventing that part of calloc by wrapping malloc.
Very interesting article! I like the fact that you mentioned Prolog as one of the less mainstream languages to learn. During my time at uni I found that both Haskell and Prolog really changed the way I approached different problems and gave me a high level perspective to problem solving. Some interesting resources to learn Prolog:
I did some Prolog programming too for fun, and boy! it requires a complete paradigm shift in thinking! For those unfamiliar with Prolog, Prolog is very different from procedural programing languages. In procedural languages like C and Python, we assign values to variables and ask the computer to do operations on them. In logical programming langauges like Prolog and LISP, we tell the computer truth values of a list of statements, and ask the computer to check truth values of other statements using the provided list.
In the past, Prolog and LISP aimed to become the go to language for Artificial Intelligence programming. Sadly, not many people use them any more.
(Common) Lisp is a multi-paradign language. It doesn't have any specific logic programming features, no more than any other generic language. Some lisps tend to lean towards functional paradigm. EDIT: OK, maybe Lisps' symbol type helps a bit on logic or AI but there's no built-in resolution algorithm like in Prolog.
But Prolog is really something different. I only know some basic ideas but definitely want to dig deeper in the future.
I'd also add Elixir as an alternative to Erlang. Still a different way of thinking if you're an imperative programmer but has nice tools and perhaps a familiar syntax.
I agree that it's important to unplug every once in a while, but for some, programming is like reading. As an analogy consider a lawyer reading legal documents all day at work and going back home and reading a novel, it's exactly the same for me, working on my own projects is exciting and enjoyable.
"With the first link, the chain is forged. The first speech censored, the first thought forbidden, the first freedom denied, chains us all irrevocably."
Music industry should die for what it's trying to do with our liberties.
At 80x24:
gnome-terminal:
Alacritty: At fullscreen:gnome-terminal:
Alacritty: The font was a tad smaller by default on Alacritty, changing it made no significant difference in the numbers. Since the difference in performance was quite noticeable I decided not to test other possible configurations, but I could do so if it might help.My graphics card has a pretty poor performance in general so that might be an indication that, since the performance of Alacritty is directly impacted by the graphics card, it might be useful for the author to determine the "minimum requirements" for Alacritty to outperform the competition.
In any case, it might not be a fair comparison as the author has stated that this is a pre-alpha release, but maybe he can find it helpful in some way, as he suggests he hasn't been able to find a test in which Alacritty didn't perform as well as another terminal.