Why do I even anser.... I think because of
this....
>Why is everyone so skeptical of the Ahead of Time interface?
>The results might be surprising to you all.
>This might not be such a bad thing.
Nope, all of our emulated code is placed in RAM. Learn how to read your graphic.
> It is believed that Android will be upgrading from JITARM64 to some type of AOT(Possibly A.R.T) sometime this year.
I don't believe so. I'm the second one written code for the JITARM64, who are you?
> Source:http://www.infoq.com/news/2014/07/ahead-of-time-compiler-os
They are talking about executing JAVA. So yeah, maybe our GUI will be a bit faster....
> Why the AOT Interface (Android Run Time ) is better in performance than JIT64 orJ ITARM64 (Android).
>
http://programmers.stackexchange.com/questions/274640/why-is-android-runtimes-aot-compilation-more-performant-than-dalviks-jit
Still JAVA. Please get familiar with the topic, at least a bit.
> So for people that have ALOT of RAM (and do not have the strongest graphics card in the world-GTX 970 I'm looking at you-) on their PC or Android Device, this could be a significant speed up for you.
Still, for JAVA code. Don't mix this with our emulated PPC core. We already use native C++ code, there is no way to get faster. At top of this, we generate "native" ARMv8 code. But as the PPC code lives in RAM, and because of indirect jumps, AOT just is *NOT* possible.
> New code will not speed up an emulator, but will surely show better compatibility with hardware, in terms of performance of course.
"not speed up" vs "in terms of performance". Hell, what are you thinking at all?
> So again, if you're that guy or gal with (for example) 32GB Ram and a 2GB VRAM Graphics Card, this is up for grabs.
Neither VRAM nor RAM matters for us, we just need plain CPU power.
> An AOT recompiler would use less CPU and RAM for actual ROM (Reading only Memory) from your motherboard.
Bad luck, we're emulating from RAM...
> Therefore, an AOT recompiler for dolphin would use the resources it needs to run applications like itself (and only itself lol) at a BEAUTIFUL speed.
Still no. Repeating doesn't make this assumption more correct.
> Though mind that 64-bit windows or Linux is your best friend when it comes to your actual computer's ROM(Reading Access Memory) size.
What is "Reading Access Memory"? There is read-only memory (ROM) and random access memory (RAM). But still no, 64bit just increase the amound of virtual memory (*not* VRAM). It allows us to alloc more virtual memory than the 32bit one on the Wii itself (4GB). Hint: This has no requirement on the physically available memory.
> I mean, in my opinion, an AOT (CPU) Interface and the Vulkan Graphics (GPU) API would go beautifully together.
This is likely true. But just because it's your opinion doesn't tell anything about it being true or false....
> This would be the best thing ever for budget low-end PC's and Android Devices.
But it won't reduce the CPU requirements for the PPC emulation.
> What does this have to do with VRAM you're probably still asking?
Indeed.
> Answer: Vulkan uses less than half of the number of Draw Calls the DirectX API does overall on an OS.
Nope, it uses less overhead, not less draw calls.
> OpenGLES vs Vulkan, check this out if you don't believe me lol.
Trust me, we already did. It's indeed much better than so many bad mobile GPU drivers. But it's not that much better than a good OpenGL implementation. Vulkan (and D3D12) gives some really nice improvements, which we can't use. No way to cache command buffers, or to generate them threaded. We have to emulate a deterministic GPU, not a game engine.
> Watch the video to see who wins maybe?
https://www.youtube.com/watch?v=P_I8an8jXuM
Massiv amount of objects, very big speedup by pregenerating command buffers. Sadly, not possible for us. This is a video of an engine, not of an emulator.
> OpenGL Killer?-
https://www.youtube.com/watch?v=uWwNlhDVS0o
Nope, different usage. For us, vulkan is likely still a bit better. But not *that* much. OpenGL with AZDO is already as good as Vulkan. And we use most of this features already. But bad luck, there are still some mobile vendors which doesn't support it. Their fault in my opinion.
> And Above it all, "The smaller the code size, the better the performance a wise man once said".
Vulkan will have a by far bigger code size.
So, in the end, I think I have to say, thank you for this funny quarter of an hour. Lots of funny assumptions, but *no one* was correct. At least, there will be some fun laughing at this post. But seriously, please read a bit more about emulation. Or just trust us that we're knowing what we're doing. Especially as the dolphin team is one of the most skilled one I've every seen in emulation.
![[Image: j-l-table.jpg]](http://archive.linuxgizmos.com/ldfiles/misc/j-l-table.jpg)