civility

You're working from old information. Show me a benchmark where Fortran wins over C or C++ any more. Those days are gone. Here's my line in the sand:

    https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html

As for GPUs, no contest.

If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell.

> So let's get back to the performance of the code generated by the Rust compiler, shall we?

"Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality of life.

> I never claimed this.

No, the person I first replied to did. Then you jumped in and defended his position with your "yes and no" comment.

> I don’t think we’re really gonna make any progress here so I’ll leave it at that.

I agree. I always appreciate your friendliness and thoughtfulness, but I've never gotten you or anyone else on the Rust team to budge an inch on the problems with Rust. (which is a shame, because it's close to being a great language...)

You added to your comment while I was replying, so adding to what I said in the sibling reply:

> Being able to implement something does not mean that by implementing it a different way, it will certainly be faster.

Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more.

> You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works.

Yeah, actually I can. The claim is that LLVM is slow, so it's not Rust's fault. But LLVM isn't slow when compiling a language with nearly equivalent features, so that's a poor excuse. That's how engineering, logic, and accountability work. There is nothing in Rust which doesn't have an analog in C++, and C++ compilers aren't as slow as the Rust compiler.

> note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly."

You brought FastISel into the discussion. This is just another part of the shell game. Compare clang++, g++, and rustc with optimizations on or off.

What feature of Rust requires elaborate features or massive amounts of code? C++ has stack unwinding, you can implemented dynamic dispatch in C with function pointers, and Rust's match isn't that much above a switch statement. Both C and C++ on top of LLVM compile much more quickly than Rust.

> Yes and no;

Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.

> Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation.

Considering clang generates LLVM IR and compiles much more quickly than Rust, this argument doesn't hold. The Rust compiler generates IR which chokes LLVM and makes it slow, but they didn't have to do that.

I do wish they were combined. It would be nice to handle arrays of structs and structs of arrays more gracefully, and it's unfortunate how the format strings almost (but not really) agree with each other.

And so long as I'm asking for ponies, it would also be nice if they handled complex numbers gracefully.

I disagree. The struct and array (not Numpy) modules are pretty great at cutting up binary data. You provide a format string and it just works.

> Well, as I far as I can tell, a significant portion of negative qualities attributed to Facebook also can be, have been, attributed to email.

I disagree, for me this isn't about being addictive. Email doesn't quietly let websites I visit add themselves to my apps list and periodically reset/redefine my permissions so everyone can see my (and my friend's/family's) personal information.

If Facebook was just addictive I would still use it (I ditched it over 10 years ago).

Support issues with email? Everyone I know can handle email just fine.

I consider the lack of emojis a bonus. Old school smileys are just fine by me. :-)

(Actually, emojis work just fine with gmail, but I won't be embracing them any time soon)

> Facebook gives me the opportunity to maintain contact with my family who live on the other side of the world, as I walk the streets of São Paulo, for free. [...] The alternative (cel phone calls and sms)

I use email to keep in contact with my family. CC everyone, then reply all. No Facebook required.

He's implementing his own language, so it seems it would be useful for debugging his own compiler. In other words, the IR he's generating is not really for anybody else, it's for himself.

Yeah, that works, but it's going to confuse more than half the people who ever look at it.

It's fine until you do almost any arithmetic using the index. Unsigned arithmetic is rarely what you want, and it quietly converts all of your signed types to unsigned giving you large positive values instead of small negative ones. Maybe this isn't a common use case for most people, but it came up all the time when I was doing signal processing algorithms.

Using ssize_t is pretty reasonable, and you're not going to overflow ssize_t for loop indices except in some very pathological cases on a 32 bit architecture.

If the arithmetic argument doesn't convince you, here's another one: write a correct loop (using size_t) which traverses your array in reverse order. Here is a broken example which would be fine with ssize_t:

    for (size_t ii = len - 1; ii >= 0; --ii) {

    }

> you would only be able to have an element size of 1 byte

Yes, when people point out this bug, it seems crazy. Who does a binary search of 1GB of sorted data which only contains values from 0...255 (or -128...127). I mean it is a bug, but it's also the wrong data structure for that data...

> to use a 32-bit element count on a 64-bit system is itself a more valid bug

Yes, this one is real. Even ignoring the binary search algorithm, I cringe whenever I see people use "int" as a loop index. 2 gig arrays were very common in the work I used to do.

I also cringe when I see people used unsigned (size_t) loop indices, but that's a deeper topic.

If your compiled code is thread safe, you can releae the GIL in your library and achieve parallelism with current CPython. If your compiled libraries are not thread safe, you can't get parallelism anyway.

Maybe, if your heavy lifting functions are very short lived, releasing and acquiring the GIL is holding you back...

Btw, I'm not defending the GIL. Python has enough visibility and significance to deserve a good implementation. It's just that most people don't realize the slowness of CPython itself is a bigger impediment to performance than the GIL. Python should be in the same speed league as JavaScript, but there are too many things hindering progress.

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracing PyPy) and staying single threaded than removing the GIL. At least if you're choosing threads for performance gains.

Think of it this way: A single threaded C++ or Rust program can do more work per second than a hypothetical GIL-free CPython with 64 cores...

> "Pass by reference" is a specific term for a much different technique which is very rarely encountered these days.

C++ isn't all that rare.

I suspect we'll have to agree to disagree whether your definition of pass by reference is universal. Given your definition, can you name any language with calling semantics which are not pass-by-value? I mean, you're always passing the value of something (be it the actual value, the address of the memory where the data is stored, or the pointer to the string containing the name of the data in an associative array).

You're right, it is more like a pointer. In C++, that would call the assignment operator which can do anything it wants, but the address of the Object would not be replaced. Java would change the value of the pointer in the callee.

These cross-language comparisons have too many nuances for me to try and make simple examples. Really, my original point is that CPython does not have "primitive types" as in Java. Everything is passed by pointer to the PyObject.

I'm not sure if you think you're correcting me, but it sounds like you think you've got it all figured out.

Java calls them "primitive types", btw.

I'm not sure what your point is...

Java primitives (short, float, double, etc...) are copied to the calling function, but arrays and objects are passed by reference. This is easier to explain in a language like C++, which can do either:

    // Java always does these:
    void f(Object& o) { ... } // passes objects by reference
    void g(double x) { ... }  // primitives are copied

    // Java can not do these:
    void p(Object o) { ... }  // copy of the object
    void q(double& x) { ... } // reference to primitive

CPython always passes by reference (pointer), and a C extension can break the rules and modify the otherwise immutable types (int, float, complex, string, etc...).

You can squint and say everything is pass-by-value because you can always pass pointers, but then we're really losing any meaningful definitions for what semantics we're describing. I mean, it's all pass-be-electron if you dive deeply enough.

Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languages - Java doesn't do that, for instance.

Python integers are definitely objects:

    (3).real # returns 3
    (3).imag # returns 0

Python's lexer/parser made different choices than Ruby's, so the parens are needed here.

You're right that you can't perform swaps with a Python function, but it's never pass-by-value like Java primitive types. It feels like pass-by-value because int, long, float, complex, and string are basically immutable.

Python is not efficient, but the bug you described seems like a problem with that implementation of malloc...

The Cooley-Tukey algorithm is nicely understood as a "4 step FFT". Both the decimation in time and decimation in frequency algorithms, and the "bit reversals" they use, are really just special cases of the more general (and simpler) thing.

Say you have an array of size N, where N = P*Q. You can treat your 1D array as a 2D array in row major form. Then the 4 steps are:

    do vertical FFTs of the columns
    "twiddle" the data
    do horizontal FFTs of the rows
    transpose the array

The twiddle step is really just multiplying each element in the array by a complex number. See:

    https://en.wikipedia.org/wiki/Cooley%E2%80%93Tukey_FFT_algorithm#General_factorizations

This breaks the N-size larger FFT into smaller P and Q sized FFTs. If P or Q is factorable, then you can recursively apply the algorithm to perform each of the smaller FFTs. Eventually, you'll reach a base case where you need a different algorithm. For instance, if you get to a factor of 2 or 3, you'll just do the simple DFT. If you get a large prime, there are other approaches.

If N is a power of 2, then you can always choose one of P or Q to be 2. These are the decimation in time or decimation in frequency algorithms that most people are taught. I think restricting it to this special case, and jumbling it all up with the "butterfly" diagrams commonly shown really obscures an elegant and easily understood algorithm. If you save all the transposes, and the transposes in the recursions until the end, it ends up being the bit (or digit) reversal you're familiar with. The reason bit reversal seems magical is because it hides the fact that it was really just a bunch of transposes.

I knew a guy who worked in an industry where using SSNs for identifying people was illegal. Their solution was to prefix the SSN with a leading one. Compliance.

> There's no mystery to how prior civilizations hit collapse events when I read comments like this.

You're making my case for me. I'm sure there was some doom sayer in ancient Rome who predicted the world could never support more than 10 million people tops. Yet here we are at 7.7 billion and counting.

> In the year 2018, you'd think people would be more focused on higher pursuits [...]

You've clearly got some other agenda that you're trying to argue against. Feel free to try and tell everyone how they should live, but I'm not really interested. I was responding to claims of "overpopulation".

> Until there's not or nature throws you a cyclical curve ball. See history for what the results are.

Again, you're making my case for me. Sure plagues happened... I wouldn't be surprised if in 2200 some historian will look at the archives of messages like this and snicker you thought 7.7 billion was a lot. It also wouldn't shock me if once all the third world countries have birth control and health care that we find a natural equilibrium at 20-50 billion.

Please make a prediction about what you think the current carrying capacity is. Then, assuming you live 40 more years, it'll be long enough for you to see you were wrong.

People love their doom and gloom, but truthfully there is a lot of room left for human growth on this planet.

So maybe "carrying capacity" is not a myth, but "human overpopulation now" of the planet as a whole certainly is.