mGBA is, that's why you see the performance boost.
Yes, it has 4 cores. Same speed. Why wouldn't devs want to write multi-processed code? It's the standard. They already write multi-threaded code for every other platform - vita, smartphones, ps4, xbone, pc, etc. You're talking as if multi-threaded code is something devs want to avoid.
You keep saying that but I don't think that's true.
Ctrulib is only a library of services usable in user mode, the difference you got between CIA and 3DSX are much likely related to the loader and the running application permission.
Of course it's possible. Ninjhax has very nice control over the memory (remember CitraAGB has dynarec on it, but not as a native 3DS executable). Only some of these functions have still not been been fully implemented on ctrulib.
I didn't knew about mGBA
But see the retroarch thread: all the cores used are single-threaded but still run 2x faster on n3ds.
How do you explain that?
May I ask how it was verified / confirmed ?
You can have multiple threads on a single processor core. My point was that having to choose which processor to use for each thread (which also could introduce some limitations since threads are generally supposed to run in a single process, with shared context area) was more complicated than having one core running the kernel / scheduler and another running application (with eventually its threads).
- Joined
- Sep 3, 2015
- Messages
- 683
- Trophies
- 0
- Age
- 31
- Location
- Hastings
- Website
- www.facebook.com
- XP
- 485
- Country
i refuse devolve and use the 3dsx ver.
so until its fixed ill be siting here patiently like the patient spy. lol
so until its fixed ill be siting here patiently like the patient spy. lol
Have you looked at the code to determine what it is designed for? How would you even be able to recognize threaded code if you're not a coder?
Just because an app happens to run on single-threaded hardware doesn't mean it was designed for it. You can write some random dummy java file in 2 minutes that would run much quicker on a dual core cpu over a single core, but it would still run on the single core, just slower. That's whats happening with mGBA.
*arm 11 kernel
We already have arm11 (userland, though)
I actually can read the code of those emus and do not see them making use of threads while mGBA indeed uses POSIX threads and has some layer in the 3ds port to translate them into 3DS threading services.
https://github.com/mgba-emu/mgba/blob/master/src/platform/3ds/threading.h
I'm not sure what you're arguing anymore. You just said 1 page ago that none of these emus were designed for multi-threading and that the fact that they run faster must be due to faster clockspeeds. We know the clockspeeds on N3DS aren't faster, and we know n3DS has 2 extra cores. So in this case the only option for something being faster on one system over the other is multi-threading. There literally isn't any other possibility.
Does mGBA use any of the features NinjHAX 2/OoTHax/Ironhax don't have? That'd account for it.
I haven't see any definite data with framerates on games at all though between systems, which is why the speedup thing bugs me so much.
I haven't see any definite data with framerates on games at all though between systems, which is why the speedup thing bugs me so much.
That's not entirely true.
We had a similar conversation somewhere in the Gameyob thread. I have both a n3ds and o3ds, I wrote and tested single threaded code(brute math, each iteration dependent on the previous iteration). My findings were that the n3ds ran the code something like 2.3x faster than the o3ds. I also wrote code that checked the cpu ticks in relation to the system clock. Both the n3ds and o3ds returned the same value.
So that was odd in my opinion. Someone suggested that system services have been moved to another core, thus freeing up more CPU time on the main core. Plausible but that suggests that the OS uses more than 50% of the cpu time for it's own purpose, even though it has a dedicated core.
No matter the case, the n3ds effectively has double the CPU time for single threaded code, even if the cpu clock appears to be the same.
There was something that made it so only <=9.2 could use dynarec. Was that active on both the O3DS/N3DS in those tests?
ok, thanks, i will see by my own now
is that or play the PS2 version on PC with 3DS as controller x'D
Ty anyway for the answered
Just noticed this post. It adds complexity, significantly. I've seen poorly implemented mutexes in my time. Online tutorials by people that don't know how IPCs work nor when it's safe to access data in a lock. It's a shame that it's easy to get miss informed.
Fact is, threaded code is hard. It's hard to catch corner cases, it's hard to debug, and there's always some bit of code(or worse a lib) that doesn't like threads. But most of the time, solutions to problems are simply more obvious in a single thread mindset.
More over, emulators are not so easily threadable. Basically it breaks down to an emulation thread and a render thread. This is impossible for older systems where cpu clock is tightly tied to the ppu and single instructions timing means the difference between correctly render or not. It's even harder on the 3DS since we lack render hardware capable of rendering from palate requiring CPU intervention.
Are you asking me? Dynarec only applies to emulation. It doesn't apply to these test.
... I meant whatever it was that was allowing dynarec. I don't know what capabilities are removed from the user if they're using a usermode exploit instead of a kernelmode exploit in the context of homebrew.
Dynarec's the only major performance difference I know of, and I didn't know if the capabilities that were allowing it allowed anything else remotely relevant for brute force testing.
No, the issue lies with user code not being allowed to set memory execution privileges. Only the kernal can do that, or an exploit that grant that privileges. Lacking that privilege should have no impact on performance.
Similar threads
- No one is chatting at the moment.
-
-
@
realtimesave:
Nintendo needs to release a new console, switch is getting such shitty little games lately lol it's pathetic -
-
-
-
@
The Real Jdbye:
well actually
a new console won't do anything right now, because the games are still in development, that's why there are few games being released -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
