Just installed on Ubuntu

@TSK

Quote:
It's not for me. Your mileage may vary, however. The source code is available. Go do something about it.

Cheers,
Rich

@orgin

Quote:
Probably. It's easy to get confused when there's no information to go on.

Cheers,
Rich

@evilrich

The original message was meant for the amikit linux install guide so that they could correct it. It was not meant for you. The rest of the thread however contains stuff that could use your help. But a small warning the stuff is not on the "the 68000 has a 16MB address space" level, it goes somewhat .. well you know ... deeper.

Well anyway if you really want to help you can read this message:

http://www.amigans.net/modules/newbb/ ... t_id=23103#forumpost23103

And tell us if know what's really going on in compemu_raw_x86.c (and elsewhere in the source) that makes e-uae do the wrong stuff when running in a 32Bit linux system on a dual core AMD 64Bit system (ie it shouldn't try to use the cpu as a 64 bit cpu, it's a 32bit system and should treat the cpu as a 32 bit one).

Edit:
Just a small recap: E-UAE runs terribly slow in jit mode in Ubuntu 8.04 32Bit on a Dual Core AMD 64Bit cpu. I managed to build an euae that doesn't detect it as a 64 bit cpu (I shouldn't in the first place) and it became faster, but there seems to be stuff that still gets done that shouldn't be done inside the e-uae source code (compemu_raw_x86.c).

@orgin

Quote:
I read it. As I said, there ain't much information to go on.

And what there is doesn't make much sense.

Quote:
Nah. I just make it up as I go along.

Quote:
Right. This is one statement that doesn't make any sense.

The JIT doesn't try to use the CPU as a 64-bit CPU. In that version of E-UAE, the JIT doesn't support generating 64-bit code.

What it does do, is try to detect what CPU you have to make some optimal choices about how to generate 32-bit code. It tries to pick the best alignment for jumps and loops, for example.

The only difference between detecting a generic AMD processor and detecting an AMD64 processor is that with the latter it doesn't try to avoid generating code that does partial register writes. Now, it probably should, but I don't think it would make that much difference. (If you look at AMD's optimization docs, then not doing partial register writes is nowhere on their top ten of sins). Besides which, on my AMD64 box running Ubuntu 8.04 (the same as you) a 32-bit build of E-UAE just flies.

What I think might be more likely to be a problem is with reading the TSC on your dual-CPU box. You could try setting 'x86.use_tsc=false' in your config file to verify this.

Whatever. If you really want some help solving this problem, you'll need to provide more useful information than "It's slow". Precisely what CPU do you have, for instance? How about a diff containing the changes you made to the source code? I'm not a mind reader.

@evilrich

You have such a bad attitude that it's just silly. Will you just frelling drop it and get over yourself? Do you treat everyone around you this way?

Quote:

Are you kidding, I've provided ample information in the thread (including cpu type) far beyond "It's slow". If you want more information you can just _nicely_ ask for it instead of behaving like you stand above everyone else. Noone here expects you to be a mind reader for crying out loud, this is an amiga site, not the "Optimal psychic phenomenons" web site.

Are you clear now that you need climb of that almighty horse before bothering here anymore so that we can move on and behave like adults? Or do I need to throw more garbage on you until you snap out of it?



Now what I did can be found in this file:

http://orgin.biz/~orgin/files/compemu_raw_x86.c

What I did was to remove anything in relation to AMD64 (X86_PROCESSOR_X86_64 etc). And trying to make it select an AMD Athlon cpu instead of an AMD64. From what I can tell (that is: I'm guessing) it still detects at least one cpu feature that wouldn't be detected on an athlon: Long mode.

I also removed the md-amd64-gcc/ directory from the build system. (configure and makefiles) even though I suspect it doesn't matter.

The changes were made as a long shot. I didn't bother to check more deeply what effect would be. I just noticed in the euae stdout that it had detected a 64Bit cpu and wanted to force it to detect an athlon and see if that would speed it up. The changes are not fit for using in a public binary nor do I expect them to ever be, I just did a quick hack for the heck of it as a last resort.

The only thing I have going for it is what I noticed from the emulation. It is faster, though still stalling a lot (say 030 25Mhz with some fast mem speed overall, instead of a 14Mhz 020 without fastmem running on AGA without my changes), p96 graphics operations fly and the amiga side is less prone to guru. With the standard build amikit always gurus during loading with the jit settings mentioned earlier in this thread.

Now, I'm going to try the "x86.use_tsc=no" setting as you suggested and see what comes out of it.


Edit: Nope x86.use_tsc=no didn't solve it. The emulation just either freezes up during loading (my hacked build) or gurus (the standard build) when using the jit settings mentioned earlier in this thread. Setting jit "Flags: Always generate" makes the standard build freeze up during loading instead of guruing.

Edit2: Actually it seems it was something in the AmiKit install that caused the freeze mentioned in the first edit. I tested an earlier 1.5 install of amikit and it ran fine with x86.use_tsc=no. After reinstalling the latest 1.5RC11 Amikit it also runs fine! I'm going to forward the x86.use_tsc=no thing to the beta list so that they can include it in the linux install guide. It is however required that the jit setting "Flags" is set to "Always generate" or it doesn't work.

@evilrich

PM sent.

@orgin

Which charm school did you flunk out of?

If you can't even answer a simple question like *exactly* what CPU do you have, I can't help you.

In the meantime, try this version:
http://www.rcdrummond.net/uae/test/20080815/

This fixes some bugs in WIP4, although nothing directly related to the JIT. (I doubt that the problems you are seeing have anything to do with the JIT anyway.)

@AmiKit

I missed the PM. Sorry, I don't visit here that often. I replied to your mail, though. Email is generally the best way to get in touch with me.

Cheers,
Rich

@evilrich

> Which charm school did you flunk out of?

Pot kettle black

> If you can't even answer a simple question like *exactly* what CPU do you have, I can't help you.

And you can't even ask exactly what kind of details you want that I haven't already provided. But I guess it's hard for you to formulate yourself clearly when you're busy trying to figure out the best way to feed your own ego.

Details previously provided: AMD Athlon 64 X2 Dual-Core

Other details (from cpu retail package and amd online product information): Socket AM2 (940-pin) organic micro PGA , 4400+, 2.3Ghz, 65nm SOI, 1Mb L2 Cache, 64Kb L1 cache per core, 65W, Built in either Fab 30 or Fab 36 in dresden germany, 221 million transistors, 118mm? die size, memory bandwidth up to 12.8Gb/s, totalt processor to system bandwidth 20.8Gb/s, memory supported: PC2 6400(DDR2-800), PC2 5300(DDR2-667), PC2 4200(DDR2-533), and PC2 3200(DDR2-400) unbuffered memory, memory controller width 128-bit, integrated DDR memory controller, One 16*16 2Ghz bidirectional hypertransport link at 8Gb/s, simultaneous 32 & 64Bit capable, Architectural features not previously mentioned: MMX, 3DNow!, SIMD 1,2,3, AMD Cool&Quiet, Power levels: 1.25 V/1.35 V, 1.325 V/1.35 V/1.375 V

Linux cpuid (3.3-9) information on actual system:



Windows CPU-Z (1.40) information from a similar, but not actual, system:

Name: AMD Athlon 64 X2 4400+
Code name: brisbane
Braid id: 4
Package: Socket AM2 (940)
Technology: 65nm
Specification: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
Family: F
Model: B
Stepping: 1
Ext. Family: F
Ext.Model: 6B
Revision: BG-G1
Instructions: MMx(+), 3DNow!(+), SSE, SSE2, SSE3, x86-64
Core speed: 2305.3Mhz
Multiplier: x 11.5
Bus Speed: 200.5 Mhz
HT Link: 1002.3Mhz
L1 Data: 2 * 64 KBytes
L1 Code: 2 * 64 KBytes
Level 2: 2 * 512 KBytes

I'll test your 20080815 version later today and get back here. Though WIP 4 runs just fine as stated in previous message.

@orgin

e-uae_0.8.29-20080815_i586-linux-sdl-alsa.tar.bz2 tested.

x86.use_tsc=no and it works just fine.

x86.use_tsc=yes and it work basically the same as "no" though there's momentary lockups happening once in a while when running a 3.x wb with p96 emulation (amikit). The lockups happen once every seconds or some such, lasting for half a second or so. When running an AGA demo it repeatedly alternates between running smooth for one second and the next it crawls.

Jit flags must be "always generate" or the emulated environment tend to guru.

e-uae_0.8.29-20080815_amd64-linux-sdl-alsa.tar.bz2 doesn't start, as expected in a 32bit system.

Well I did some more testing and I have to take some of my words back. Running Starstruck (TBL) demo they are all equally fast EUAE-wip4, EUAE-080815 and WinUAE 1.5.1 and this demo is watchable. So it's not a speed issue. Now I suspect that certain speed issues are related to file IO operations. I'm using a directory on the host system as Amiga partition on both systems/emulators. So it looks like they improved that part in WinUAE 1.5.0+.

It's especially the start menu in AmiKit which is very slow. And f.ex. opening drawers is slow too. (EUAE and WinUAE versions before 1.5.0. On WinUAE 1.5.0 and 1.5.1 AmiKit is much more faster and more usable.) I tried to edit one config file of AmiKit to get rid of icons in the start menu. Now the taskbar is huge vertically and I can't get it back to original size trying to put back everything I changed (I think) in that config file I edited. Unfortunately the latest Gparted for Ubuntu doesn't support creating AFFS or SFS partitions so I could test if AmiKit would work faster using native partitions. I tried to install the latest Gparted (0.3.8) but I couldn't make it to work. (And I don't know if it yet supports AFFS and SFS anyway.)

(My system is: 1500 MHz AMD Athlon, single core, 32 bit, Nvidia FX5600 ultra)

One offtopic note: Testing old Aegis Sonix 2.0 on all versions of UAE. WinUAE have had always the worst playback losing many notes and it played never good (testing with different possible emulator settings) (I don't know if it works better with much faster CPU's). EUAE on Linux (x86) is a little bit better but it's still far away from perfect playback. But strangely the same EUAE on AmigaOne and AOS4 it plays almost 100% perfectly but not fully but very close. So is it because PPC CPU's have good timers or is it because Amiga kernel is faster or pure luck or something else ?