csl

On a side note, isn't the choice of exactly four unrolls very architecture specific? As in, it works, but may be sub-optimal for your specific machine. I've done the exact same thing myself, and IIRC its performance varied a lot between which ISA it was compiled for.

This is almost what Duff's device solves, except then you need to know the length beforehand.

There is one very important tip that's missing: Follow the original coding style exactly.

Not just spaces vs tabs or block styles, but idioms and other idiosyncrasies, too. Why? Imagine reading a source repo where every second block uses different bracket styles, mixing spaces with tabs and so on. It's going to look like a kludgy mess, and will be distracting to read.

There is no correct style for most languages (perhaps `go fmt` might be an exception), only opinions.

I'm not a finance guy, but isn't that just econ 101?

Your company is valued at X, you take on Y in loan and invest some of that into, e.g., buying and laying fiber. Your company will now be valued at X+f*Y, where f is some adjustment factor. E.g. you may not get the same money back if you sold the fiber today. On the other hand, that fiber is projected to earn you some money over time.

I do agree those are huge figures, but it could make sense.

Maybe Intel C++ as well? But most people who have that book didn't buy it to write a compiler. Isn't C++ ridiculously hard to write a compiler for? While I haven't written one, I think it'd be much easier to write one for C — and for that I imagine it would very nearly suffice to have the K&R book.

Right, you could do that and probably do it well.

I was mostly thinking about the simple matter of scaling the resources and maintenance crew to tackle 4000 devs. But my biggest concern about it is that it introduces centralization into the workflow. I do truly love Gerrit, but I get a bit worried about keeping a lot of important stuff in a centralized and not so transparent database.

Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep track of their different build statuses.

Also, where I use it we have different levels of requirements for different branches (more people usually need to approve reviews on soon-to-be-released point branches). We use it for a large project in MLOCs but relatively few developers (less than a hundred). I can't see it would work for 4000 devs at all, though.

I think people get excited about his plans because he has a track record of actually delivering. Self-landing boosters on autonomous boats? A lot of people could have thought about that, but he (and his employees!) actually did it!

So when he talk about stuff like this, people have begun to pay attention.

Apparently made by Gretel: http://gretelny.com

This was running user-facing, in production? Do you have any experience with scaling Z3? I'm thinking large problems running on many machines, contra many small problems on many processes.

For some reason, I always imagined that SMT was used to verify stuff before putting it into production, but this opens up a whole new world of ideas for me.

Previous discussions: https://news.ycombinator.com/item?id=11132713 and https://news.ycombinator.com/item?id=11104124

The actual posters are at http://www.jpl.nasa.gov/visions-of-the-future/ — click on an image, scroll down and you can even download a PDF (non-vectorized, unfortunately) or a high-resolution TIFF.

Do you happen to blog? Would absolutely love to read about best practices, curious situations and so on.

If you haven't heard it already, there is a really good and candid podcast interview with Pieter Hintjens over at Software Engineering Daily: http://softwareengineeringdaily.com/2016/06/23/death-distrib...

Also, the original Lucasfilm Commodore 64 games, such as Maniac Mansion, were cross-compiled on UNIX workstations, transferred over the network and uploaded to running C64s — way back in 1987! (Source: The Thimbleweed Park podcasts [0], which I highly recommend.)

[0]: https://blog.thimbleweedpark.com

There is indeed a much easier way: Just create `.so` libraries (with a C interface, for example) from go or rust, as they compile to native code anyway.

I wouldn't use wcc for that ever, only for reverse engineering and similar things.

It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement).

Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs) — and may not even make sense on a given system. So shipping with -Werror is not really a good idea. Put the important stuff in the tests.

I feel that this is so important that I'll just quote the central part of Aaronson's response:

  OK everyone: At several people’s request, I’ve now taken
  a look at arXiv:1403.7686, and I can confirm that it’s
  complete garbage.

Aaronson explains why, too.

I emailed him in December, asking about the possibility to cross-reference VRscript snippets like you can with HTML and JavaScript. He replied he was hoping to take it in "a URI like direction", but that there was a "significant security review that needs to go on".

A(nother) cool thing about Racket is that they use GNU Lightning for JITing. Not only is the generated code decently fast, but the actual JITing is very fast. Last time I looked, the runtime compilation was considerably faster than LLVM. It matters more than you'd think.

LibFuzzer runs in the same process as the code you want to test, right? Doesn't that mean you have to take special care to recover from errors? I mean, if it messes up the heap, for example, it would be possible but tricky to continue running. And continue is what you want, because then you save a process restart when exploring the parameter space (which makes it very fast).

To me it seems like he's talking about plain CPython, which isn't even in the same class as Node.js/V8. As you mention, the correct comparison would be against PyPy.

I'm always wondering if such images are in false color. Does anyone know about this one?

If you often wonder about such things, I highly recommend the book "Advanced programming in the UNIX environment" by Stevens/Rago: https://en.m.wikipedia.org/wiki/Advanced_Programming_in_the_...

It covers a lot of stuff in an authoritative way. For example, how one should implement a daemon properly (e.g., chdir to root to allow for unmounting the disk the program originally ran from, lots of stuff like that). I'll actually doubly recommend it, because it's so good.

Oh, well, then I stand corrected. I thought it was by and large dropped in 64-bit mode? (I remember a lot of segment usage in 32-bit, but I only ever coded in real mode back in the day...)

That's rather surpising, coming from someone proficient in C. Perhaps you only need to discover the close connection between C and assembly.

The layer between them is really razor thin — by learning a few C idioms (function prologue/epilogue and the stack frames, argument passing, etc.) you'd be well on your way. You also need to start writing simple asm code as soon possible; only reading about it won't make it stick.

Having taken up x86 assembly coding again after many, many years (last time was on a 486, really), I find 64-bit assembly much easier to get started with compared to 32-bit: Simpler calling convention (on UNIX, at least), no segments, more registers, etc. If anyone is starting out, this is a pretty good time to do so.

Unless I misunderstand you, I thought the exact opposite was true: The separation of source from binaries is what made UNIX a success. When C was designed, it allowed one to take the source from one machine to another, disregarding the underlying machine architecture.

Note that I don't know anything about SGX, but skimming very briefly through the first part of the below slides [1], it may look like it's just the ability to create — at runtime — special memory regions that are unreadable outside of the process space (as in, when the region is created, even root can't unscramble that region).

Or are we talking about execution of pre-encrypted code on disk that the machine owner can't disassemble? Because the former sounds like a good idea, while the latter sounds like an insanely bad one.

[1] https://software.intel.com/sites/default/files/332680-002.pd...

You don't need to go to such complicated lengths. Just perform enough tests (as in, a statistically large enough amount) and a distribution will form. That also captures the variability of real world network effects.

While true for large demos, the 4kb — perhaps even 64kb? — are still written very much by hand.

Haha, thanks for spotting that! It should lead to the link in the above comment of course.