vardump

> Because the limiting factor isn't code generation speed, but pattern recognition. Also, having spent too much time staring the mangled junk produced by optimizing compilers that concentrate …

Nice idea how to get type checking. I was thinking more of a macro that initializes a function pointer with a code generator and subsequently overwrites it once JIT has been completed. Sadly in both c…

Currently CPU capabilities can even change on the fly, because of virtualization technologies like vMotion. That's why CPUID flags need to be masked by the hypervisors to hide CPU features that s…

Cough existing codebase cough . We can significantly boost performance for some aspects of C/C++ in the meanwhile by JITting. "sprintf" is just slow. (side note: Also C++ "<&…

It might be acceptable for some subset of "embarrassingly parallel" problems. For other problems, writing OpenCL code that even approaches hardware potential is very hard. We might need othe…

Just take a look at the code they generate, it's easy. In short, they do generate SIMD code, but very rarely take advantage of vectorized execution.

When I talk about JIT, I think primarily specialized form of them. I don't see much potential in JVM in its current form to be able to take advantage of this. Currently pattern detection and intr…

It's worse than that. It's still problematic to even assume SSE4.2, not to mention AVX2, which would help significantly. Virtualization is making the problem worse, because hypervisors set C…

Compilers are not quite up to the task, I think. I think those performance ratings are unfair in comparison to true potential between those CPUs. I think the latter is 2-3x faster given optimal instru…

Warning: link auto-plays video with sound. Edit/addition: AVX-512 in Skylake is pretty exciting. 32 FLOPS per clock cycle per core is amazing. Also good to see 64 or 128 MB of eDRAM being include…

Yes, that's exactly what I meant. Those "small interpreters written in a compiled language" have no chance against Just-in-Time compiled code.

The JIT advantage is the runtime information. Only benchmarks will always run the code in same way. Any useful piece of software runs under different conditions in different invocations and situations…

AOT doesn't exclude JIT! Doing both is the winning combination. AOT will ensure fast start-up time and JIT will ensure optimization to runtime conditions. It's tricky I'm sure, but it&#…

Yes. They're all compilers. Static compilers just limit themselves to generating and caching code just once, one size fits all. Dynamic JITs can do all that and adapt at runtime. You could even s…

It can do simple control flow analysis and data flow analysis and generate the constraints out of that. It doesn't even need to be right, if there's a proper guard condition in the generated…

There's absolutely no reason why there needs to be a warm-up period. You can cache the JITted binary code to disk. CPUs really don't care how the code was produced. A sampling profiler can b…

Yeah, same silly things programmers do in real world statically compiled code. Bad choices for something like data type and bad compiler options. A JIT can figure out negative numbers can't happe…

Yeah, it might be worse at allocating registers, but on the other hand it can often free registers as well. Static compilers just don't have the runtime information to take advantage of. Some may…

Yeah, I do. Kind of. Static code carries a lot of overhead in some cases. SwiftShader is a specialized JIT. It generates the code at runtime. It beats any C-code by about an order of magnitude. https…

There's also a significant overhead for not being able to target exactly the CPU model and parameters for the call at compile time. Unless of course doing profile guided optimization just for tha…

Plain C++ can easily lose to JITted scripting languages. Nothing new or weird in that. Remember, we're comparing native code to native code.

Lossy compression might be just fine for source code, as long as the lossy part is still functionally equivalent. Think 1000.0 vs 1E3, printf("foo") vs puts("foo"), etc.

Yeah, although pretty often getting that 2x on non-vectorizable code is about doing a different thing that maps better to the hardware. Mostly you just have to do what is outlined in the next few para…

Better be careful though. Sometimes compiler generated output that looks stupid is correct. And what you think is faster, is not faster or correct. Such as signed division by two by strength reduction…

You don't need assembler for that. Just use compiler intrinsics, they usually compile down to a single instruction.

You'd learn x86-64 assembly to better understand how your high level code maps to the CPU. To see through the level of abstraction you're using. So that you don't do senseless things in…

> By the same token, I'd assume it's usually possible to get a 100% speedup by dropping to hand-coded assembly (1:2), and wouldn't be surprised by 5x-10x especially if one is allowed…

Regexp JIT was already mentioned. It's notable that regexp JIT technique is being used by practically all high performance regexp libraries already. Such as these: * Perl and PCRE: http:/&#…

I think Java's issue is not really due to garbage collection directly, but overuse of references (pointers) leading to very complicated object graphs. This in turn leads to a lot of pointer chasi…

Enough RAM? That's about the only thing why 64-bit processor is not needed in a phone. 32-bit ARM can support up to 1 TB of RAM.