Rochus

So we are glad that we can use the data of the memory mapped file directly and do not have to allocate or copy anything. But of course you may solve the problem badly if you prefer so; after all, ther…

Yeah, right. The people who know this can apparently be counted on one hand when I look at the advertised publication and the discussion in this forum.

See https://en.wikipedia.org/wiki/SAM_(file_format)

But most life scientists using the library for their work are not; Go is a language they can master, as well as Python or Lua; if they're biophysicists they're likely to know Fortran and C a…

The problem starts with the design decision to stream the file into memory; if you map the file instead you can directly use the mapped data and only have to allocate supporting structures (if require…

Common Lisp: It is permissible for an implementation to simply ignore such declarations. And you still have to copy. Ref counting: only makes sense in a few special cases. Avoiding dynamic memory mana…

Of course you can use better allocators; but it's faster to avoid dynamic allocation (e.g. by pointing to memory mapped from the input file by the OS) altogether. If they allocate memory for each…

People often forget that memory allocation is very expensive; the C/C++ default allocator is very inefficient.

> Common Lisp also lets you use mmap But not without allocating dynamic memory and copying data. > They clearly wanted automatic memory management Most likely because of some misconceptions. >…

I think this applies to any kind of advanced software development or programming languages, not only C++. There may be many reasons why scientists who are not computer scientists feel more comfortable…

In C/C++ we have the possibility to avoid dynamic allocation altogether and to use system features like memory mapping. If we use C++ the same way as Java (everything dynamically) it's not t…

I had a quick look at the C++ source code provided at https://github.com/ExaScience/elprep-bench/tree/master/cpp . As suspected, everything is dynamically allocated…

> Prolog can occasionally feel more general purpose That's subjective; Prolog is/was not intended to be a general purpose programming language, as little as e.g. SQL. And human imaginatio…

Lisp is a general purpose programming language, supports any paradigm and the implementation of domain specific extensions. Tool and library support is very good and there is abundance of tutorials, b…

Prolog is rather limiting; that's why Lisp has established itself in traditional AI and especially in algorithmic music composition/generation too (see e.g. Experiments in Musical Intelligen…

The word "monoculture" means something completely different. LLVM is by definition no "monoculture" because it integrates a diverse set of function and is developed and maintained …

You can write in a contract whatever you want; it's permitted to sign invalid contracts; but it's the court which decides on the nature of the contract and interprets the will of the parties…

So if we join forces and create a reusable compiler backend so not every compiler writer has to implement the same optimizers and code generators over and over again, then this is bad because it'…

As I said, I don't know US law. But I studied Swiss law which is quite similar to the law of other European countries. Even though Apple is a large company and sometimes behaves as if they are ab…

Knowledge by itself is no issue and not subject to copyright. But you have an issue if you use code or libraries (i.e. everything which qualifies as a "work") or patents of which you're…

This is regulated differently in the different countries. It is common that the intellectual property you create in the course of your employment automatically belongs to your employer. But of course,…

Their secret police will still come after you, even if you change jobs.

Now it's called monoculture? Rather strange. But anyway: in your terms you're just replacing LLVM monoculture by Rust monoculture, isn't it?

I'm located in Switzerland, do my own acquisition and I have long-standing, stable cooperations with companies where I am known and trusted. I also regularly receive requests from recruiters wher…

Very interesting study, thank you Gitlab. It would be great if the results were true and the trend could prevail in the long term. I'm one of these 16% "working remotely all the time" s…

I guess you already have seen this article: https://en.wikipedia.org/wiki/History_of_computing Here some other interesting books and articles: https://www.amazon.com&#…

Very interesting, thanks. I also find it remarkable that most affiliates of both papers are from the UK.

It's still a "proof by induction". There is no reason to conclude from the individual cases that it works in all cases.

Very interesting paper, thanks. It was time someone looked into it. I can't take these equally populist and unsupported reports anymore that some neural network is doing better than a medical spe…

No, you cannot make this conclusion from my statement.