@phoenixkonsole: sorry, but you continue to make mistakes. He was not referring to SIMD, but to the architectural differences between x86 and x64.

In very short: x86 has only 8 general purpose registers (and SIMD registers too). x64 has 16 (for both). So, x86 allows to MUCH BETTER map the registers from the emulated architecture, without resorting to use the stack as a storage for them.

I hope that now you understand.

Anyway, as I've written before, you can also use 64-bit data, which sometimes help a lot implementing algorithms, and then reflects the benefits on performance.

64 bits are not only for addressing more memory. Absolutely.

Last but not least, you can use 64-bit memory addressing to make 32-bit running better. Even an Amiga/-like o.s. can take advantage of it, moving some data structures to > 4GB address space.

@cdimaurio
Compilers are optimized to make use of new instructionssets as well.
Namely
SSE4.1/4.2, AVX and what not ever. My Responses has a theoretically nature and is only valid if
1. Overall instructionsets and Bus is identically
2. you don't need to fill more than 3.5gb (and so do no Paging)
3. you don't have a optimized compiler (optimized for new Chips only or more adequate)
The truth is that 64Bit is the Future . I just say that 64Bit alone is not faster.
Mplayer fits good into the Imaging and Video categories where i Said That 64Bit is better Suited.
Here again doesn't count my Argument with the Lenghts of a instruction to the CPU.
The decoding is faster than the waiting Time for the next instruction.
But is this true for all Codecs? Whatever you are right : )
64Bit is faster -but not always. You need just the right Benchmark ; )

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@phoenixkonsole
Hmm why not using 128bit cpu's. Maybe because our videocodecs and pictures are not Heavy enough yet. It is just about Memory ; )
Kidding - Forget it : )
Have a nice Day.


@cdimaurio
Yes i Understand and that makes Sense if it works.
Ok One Point more for 64Bit. I also Understand that it Opens new ways for devs.
Ok ok you won ; )
I am now Holding the 64 Bit flag.

Wouldn't make 128bit be better . Opencl + gpu ?

Last edited by phoenixkonsole on 22-Aug-2014 at 06:54 AM.

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@phoenixkonsole

Quote:

phoenixkonsole wrote: @broadblues ... Imaging (2D), Video-Editing benefit the most. Since videos are getting bigger and even Photos go into the multimillion Pixels.. 64Bit is the way to go.

As such things always were the strength of classic amigas in the past, 64 Bit is a 'must' for the Amiga.

Quote:

phoenixkonsole wrote: ... Do you edit videos? No. ...

Of course!

Don't take for granted that all Amiga users are just interested in playing silly shooter games etc. on their devices! There are still some users like me who want to use their Amigas for serious tasks!

And I'd really like to be able use an Amiga again for video and photo editing and a lot of other productive things.
But as resolution and filesize of photos and videos grew over the years, while the classic Amiga HW did not become faster, I had to buy WIntel boxes to be able to get such tasks done in a reasonable time...

This week my good, old A4000 PPC comes in useful again: I'm scanning hundreds of old photos using the A4000 PPC with OS 3.9/WarpOS and FxScan/ScanQuuix with my good, old Epso0n GT-6500 SCSI scanner - eveyone around is amazed how well this 21-year-old machine (MoBo) is still able to cope with that task!
Really works like a charm...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@phoenixkonsole

Quote:

phoenixkonsole wrote: @WolfToTheMoon ... Whatever.. 32Bit is executed faster than 64bit even on 64Bit CPU'S .... : ) 1-2%...

Ahhh- so this must be the reason why my 32-Bit single core box @ 2.5 gHz is so significant slower than the 64-Bit Quadcore machine @ 2.5 gHz here at work on every task...

Quote:

phoenixkonsole wrote: But also this will be compensated by optimized compilers (and non-optimzed 32bit compilers because no one cares)...

So you are saying that all the Amiga 32 Bit compilers have never been optimised?

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@phoenixkonsole

Quote:

phoenixkonsole wrote: ... You need to fill first a 64bit long description before the CPU execute it. A 32Bit description of what to do next is of course "sended" quicker. And so it is executed quicker. ...

A 64 Bit CPU can grab a 64 Bit data word in one go within one CPU cycle.
A 32 Bit CPU needs to grab two times for that and needs two CPU cycles for that.
So the 64 Bit CPU is faster!

Last edited by Dandy on 22-Aug-2014 at 09:19 AM.

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@cdimauro

Quote:

cdimauro wrote: @phoenixkonsole: ... Last but not least, you can use 64-bit memory addressing to make 32-bit running better. Even an Amiga/-like o.s. can take advantage of it, moving some data structures to > 4GB address space.

Isn't that what is done on the CyberstormPPC?
IIRC, its Ram is organised as 64 Bit...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@Dandy

Quote:

A 64 Bit CPU can grab a 64 Bit data word within one CPU cycle.

This is what i try to tell you.
But what if you do something which fits in a shorter description and don't need 64bit Long Messages...
A 32 bit message is shorter and so faster transmitted and executed.

A 64Bit CPU waits until it got 64bit "full" until it does anything.

This is the theoretically valid reason a 64Bit is slower as long you can define a Operation with 32Bit in a single cycle.

Say yes, and I agree that modern world will use 64Bit anyway.
The CPU asks for 64bit Long descriptions on what to do next...
This is "longer" ... you Need to define easy Tasks in more complicated things to make the cpu do anything.

Sure... MODERN CPU's overcome that with additional instructions and compensate that... sure! I know.
But again:
64Bit is not faster automatically. It produces Overhead if you throw "boring" Task at the cpu which could be also defined in a 32bit or less description.

... your 32Bit cpu has obiously less L2 and L3 Cache, misses a lot of instructionsset which are mostly predefined instructions to reduce the waiting for short descriptions. This is nothing you could also include in a 32Bit design.

Again.. 32Bit is dead and so vendors add modern stuff to 64Bit designs... I know, you know and so modern 64bit CPU's are faster than outdated 32bit ones... but not because they are just 64Bit.

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@Dandy
you said you edit Videos and manipulate Images?
What Software are you using on Amiga? And did you reach a barrier yet ?

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@phoenixkonsole

Quote:

phoenixkonsole wrote: @Dandy you said you edit Videos and manipulate Images? What Software are you using on Amiga? And did you reach a barrier yet ?

Yes, I do.
But not on the Amiga nowadays:

Quote:

Dandy wrote: And I'd really like to be able use an Amiga again for video and photo editing and a lot of other productive things. But as resolution and filesize of photos and videos grew over the years, while the classic Amiga HW did not become faster, I had to buy WIntel boxes to be able to get such tasks done in a reasonable time...

In the past I used ArtEffect (with WOS plugins) for editing photos, but it is too slow for todays highres pics on my A4000 PPC with OS 3.9/WarpOS and often enough my 128 mB Ram are not sufficient. And in the 'swapping mode' AE is even slower...

Currently I'm beginning to test a beta of 'photo2video', a Hollywood-based program. But it isn't of much use on my A4k PPC, as it is way too slow there (although being compiled for WarpOS)...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@all

This has been discussed for other emulators / systems long time ago, and they already came up with the conclusion that, unless it is a very hard work to start (because the emu is too dependent of 32 bit code, weirdo, ...), they always get a significant performance improvement.

And we just can take Dolphin as an example:

https://forums.dolphin-emu.org/Thread-x86-vs-x64?page=2

I've not read all the comments, just post my thought on it, and I think it can only help AmigaOS4. I think anyone who was going to buy OS4.1 for classic system would of done so by now, so it may create extra sales and more reason for continued support for the classic version of Os4. Ok piracy is a slight issue and you could argue that now people can get a quick taste of the OS people might not bother with buying the new hardware, well again I would argue people who are interested enough should of really bought the hardware by now and plus the fact of the matter is looking forward, specially with Os4.2 when it ever happens seem to only really befit people with AmigaONE hardware not so much the classic systems.

_________________
AmigaNG, YouTube, LeaveReality Studio

@phoenixkonsole

Quote:

phoenixkonsole wrote: @Dandy ... A 32 bit message is shorter and so faster transmitted and executed.

But only if it is just one 32 bit word.
As soon as there is a (much) greater amount of data, you're better off if your CPU can grab 64 Bit in one go with each CPU cycle.

Quote:

phoenixkonsole wrote: A 64Bit CPU waits until it got 64bit "full" until it does anything. ... The CPU asks for 64bit Long descriptions on what to do next... This is "longer" ... you Need to define easy Tasks in more complicated things to make the cpu do anything.

I highly doubt that.
I don't think that on my 64 Bit machine here at work the data is organised in a way that it always is exaclty divideable by 64.
If what you said was right, the machine wouldn't do anything, as there will be fractions of 64 Bit most of the time...
I don't think that the CPU stops working just because only e.g. 53 of the 64 Bit of the data word are used among all the full 64 Bit words.

Quote:

phoenixkonsole wrote: This is the theoretically valid reason a 64Bit is slower as long you can define a Operation with 32Bit in a single cycle.

I think the emphasis here is on 'theoretically'...
In the real world this would rather be an exception...

Quote:

phoenixkonsole wrote: ... But again: 64Bit is not faster automatically. ...

I dare to differ.
If you take e.g. a 1 gHz cpu.
The 1 gHz mean that one cpu cycle exactly takes one billionth of a second.
And if you can grab and process 64 Bit instead of 32 in this one billionth of a second, you're automatically twice as fast as if you just could grab and process 32 Bit.
Easy as that...

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

@broadblues

Quote:

This argument is bol****** if I may say so, the same old excuse for piracy as ever, "it doesn't matter if I steal you music, I wasn't going to buy it anyway" if your interested enough to pirate it your interested enough to buy it.

Before using questionable names to others' arguments, you should always remember you're neither God in person, nor anyone whose POV should be anyhow more important than others'.

In particular, your latest statement "if your interested enough to pirate it your interested enough to buy it" is extremely questionable and - IMHO - much farter to truth than the one you're arguing against. Buying something is, always, an action that requires a prior evaluation: you may be curious, interested or in the need of something. In the third case you must buy. In the second case you can decide wether to buy or not. In the first case you won't buy and stop. This is true for operating systems but also for music, cinema and everything else: if you pirate a song is exactly becase you don't think that song worths your money, stop dot. We may question that today there are many legitimate ways to listen to music (streaming, youtube...), but this does not apply for operating systems.

After all, everything goes along with your attitudes. I would never ever buy a license of OS4.1 Classic just to emulate it (I can see it on my SAM440ep), this does not mean, however, that i would not buy it if I'd find a USE for it (for instance: creating a script in Icaros to integrate its file, in a future port of WinUAE to AROS, or develop applications and test them, etc). But, you see, I'd be in the NEED for a copy to legitimate do what I want. The gray area of 'interest' is maybe the one we can question about forever, but please don't start from the assumption that "a little interest" always is a good motivation to place hands in the pocket, since this is not true at all, no matter what copyright lobbies have to say.

kind regards

p.bes



edit: typo

Last edited by paolone on 22-Aug-2014 at 11:50 AM.

@Dandy

Quote:

Quote: Last but not least, you can use 64-bit memory addressing to make 32-bit running better. Even an Amiga/-like o.s. can take advantage of it, moving some data structures to > 4GB address space. Isn't that what is done on the CyberstormPPC? IIRC, its Ram is organised as 64 Bit...

CyberStorm PPC (and CyberStorm MK III) had 64-bit wide memory bus which has advantage over 32-bit memory bus. They can not address more than 4 GB RAM and general purpose registers are only 32-bit wide.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Quote:

phoenixkonsole wrote: @cdimaurio

cdimauro, bitte.
Quote:

Compilers are optimized to make use of new instructionssets as well.

Compilers are optimized to make use of any kind of instructions, IF it's possible and makes sense (e.g.: I don't expect that they can use an AAS instruction on x86).
Quote:

Namely SSE4.1/4.2, AVX and what not ever. My Responses has a theoretically nature and is only valid if 1. Overall instructionsets and Bus is identically

Is it OK for you having the same processor / computer, but one time running in x86 mode and another time in x64 mode, to see only the differences due to the different ISA used?
Quote:

2. you don't need to fill more than 3.5gb (and so do no Paging)

Why are you putting such limit? You should take advantage of ALL that a processor gives you.

Anyway, even keeping this constraint we can do the comparison.
Quote:

3. you don't have a optimized compiler (optimized for new Chips only or more adequate)

In real world you have a compiler which tries to optimized as best it can, whatever is the target architecture.

The new architectures have a disadvantage, because it requires time to update the compiler to squeeze as much as possible from them.

So, the opposite of your sentence is true in real-world, and an old, well-known architecture, is generally more advantaged.
Quote:

The truth is that 64Bit is the Future . I just say that 64Bit alone is not faster.

It depends on the ISA. Looking at x86 and x64, on average the latter is faster.
Quote:

Mplayer fits good into the Imaging and Video categories where i Said That 64Bit is better Suited.

I don't think so. MPlayer just plays videos, and you don't load a whole video in memory, even if you have enough RAM to hold it all inside.

MPlayer can take advantage of 64-bit for some other stuff (e.g.: filling memory, moving memory, etc.) thanks to the fact that you can handle double the data at the same time. But usually a SIMD unit is a better candidate for this.

So, say that MPlayer can take little advantage of the 64 bits. The better results most probably come from the better ISA (e.g.: more registers available).
Quote:

Here again doesn't count my Argument with the Lenghts of a instruction to the CPU. The decoding is faster than the waiting Time for the next instruction.

Decoding x64 instructions requires more effort than x86 ones, because on average there's a new prefix (REX) to be used to access the new registers and/or to force the 64-bit size.

But this penalty is greatly balanced by the huge performance improvement due to the new ISA (read: mostly thanks to double the registers available).
Quote:

But is this true for all Codecs? Whatever you are right : )

It depends on the codec, of course. But, as I stated before, you don't load a whole video on memory before using the codec. So, you don't need >4GB of RAM neither the ability to have virtual address > 4GB.
Quote:

64Bit is faster -but not always. You need just the right Benchmark ; )

Of course there are benchmarks where x86 code runs faster than x64 one. But, on average the latter runs better.

Quote:

phoenixkonsole wrote: @phoenixkonsole Hmm why not using 128bit cpu's. Maybe because our videocodecs and pictures are not Heavy enough yet. It is just about Memory ; ) Kidding - Forget it : ) Have a nice Day.

Pascal, if you were a computer architecture aficionado you could give the answer by yourself. Since it's clear that you're not, I give you a (very short) one.

128-bit for address space is too much. Even 64-bit is too much; in fact many architectures uses LESS bits for virtual addresses. x64, for example, uses only 48 bits (the topmost 16 bits are not used; they should be all clear or all set, in the so called "canonical form").

128-bit for data... can be. But SIMD units already give you this possibility, and... even more. So it's better to use them for data manipulation.

Conclusion: better have a 64-bit architecture, and a good SIMD unit.
Quote:

@cdimaurio Yes i Understand and that makes Sense if it works. Ok One Point more for 64Bit. I also Understand that it Opens new ways for devs. Ok ok you won ; ) I am now Holding the 64 Bit flag.

Sehr gut.
Quote:

Wouldn't make 128bit be better .

No. See above.
Quote:

Opencl + gpu ?

It's a total different thing. You can take advantage of them, since even the crappiest PC have a lot computing units that can be used to offload some work from the CPU.

But, as everything, it requires time. A LOT of time.

Last but not least, you cannot do it for everything. Example: try to offload 68K emulation to a GPU...

Quote:

Dandy wrote: @cdimauro Quote: cdimauro wrote: @phoenixkonsole: ... Last but not least, you can use 64-bit memory addressing to make 32-bit running better. Even an Amiga/-like o.s. can take advantage of it, moving some data structures to > 4GB address space. Isn't that what is done on the CyberstormPPC? IIRC, its Ram is organised as 64 Bit...

Not, it's a completely different thing. For example, you can have a 32-bit Amiga o.s./-like running on a 64-bit architecture, which uses the >4GB memory to implement a (statically sized) Ram Disk. It's just an example of what you can do.

Quote:

phoenixkonsole wrote: @Dandy Quote: A 64 Bit CPU can grab a 64 Bit data word within one CPU cycle. This is what i try to tell you. But what if you do something which fits in a shorter description and don't need 64bit Long Messages... A 32 bit message is shorter and so faster transmitted and executed. A 64Bit CPU waits until it got 64bit "full" until it does anything. This is the theoretically valid reason a 64Bit is slower as long you can define a Operation with 32Bit in a single cycle.

Why you should use 64-bit words for everything? A 64-bit architecture lets you use BOTH 32 and 64-bit, as you need. It "just" ADDs a new data type. So, if you need only 32-bit for some data... continue to use this size!

The only thing which doubles with a 64-bit architecture is the pointers size. Here, you can do (almost) nothing: you have to keep this size.

But for ALL other data you aren't forced to use 64 bits.
Quote:

Say yes, and I agree that modern world will use 64Bit anyway.

It's obvious: it has too many advantages.
Quote:

The CPU asks for 64bit Long descriptions on what to do next... This is "longer" ... you Need to define easy Tasks in more complicated things to make the cpu do anything. Sure... MODERN CPU's overcome that with additional instructions and compensate that... sure! I know. But again: 64Bit is not faster automatically. It produces Overhead if you throw "boring" Task at the cpu which could be also defined in a 32bit or less description.

See above: it's not true. Not at all, to be more precise.
Quote:

... your 32Bit cpu has obiously less L2 and L3 Cache, misses a lot of instructionsset which are mostly predefined instructions to reduce the waiting for short descriptions. This is nothing you could also include in a 32Bit design.

Not true: you can have the SAME processor running in 32 or 64-bit mode, using exactly the same L1, L2, L3, and instructions. Or even more in 32-bit for x86, since x64 removed some of them (too much old / legacy).
Quote:

Again.. 32Bit is dead and so vendors add modern stuff to 64Bit designs... I know, you know and so modern 64bit CPU's are faster than outdated 32bit ones... but not because they are just 64Bit.

It happens ALSO because of that. Especially because 64-bit = new ISA = new features which are NOT only related to the ability to manipulate 64-bit data or having 64-bit pointers.

Pascal, I think that it's better that you take a BETTER look at the differences between x86 and x64.

And since you're so active on pushing AROS and so taliban about 32 bits, maybe you can invest some time and resources to make it available x32 AROS version.

For x32: https://noggin.intel.com/intelpress/feed-item/the-x32-abi-a-new-software-convention-for-performance-on-intel-64-processors

In short: the ISA advantage of x64, but using 32-bit pointers. It means that you have an additional increase in performance running code in x32, compared to x64 (which, itself, runs faster than x86 on average).

P.S. Sorry, I've no time to check and fix errors. Get the text as is...

@cdimauro
Thank you for your explanation. I learned new things. X32 is again new to me : )

_________________
AROS Broadway - AEROS - Aminux - AmiCloud - indieGO! Appstore - AmiWallet - VAN lossless video codec - AMC Amiga media Center -KrypUnite - LibertyNet - MinX - amigaNX

@phoenixkonsole: it can be interesting to use for low-end machines. Nowadays almost all PCs support x64 as architecture, but many are shipped with few memory ( less than or 4GB). For these, I think x32 can be a better choice.

So, I hope to see soon an x32 AROS version.

EDIT: the forum has problems with some characters.

Last edited by cdimauro on 24-Aug-2014 at 06:59 AM.
Last edited by cdimauro on 24-Aug-2014 at 06:44 AM.
Last edited by cdimauro on 24-Aug-2014 at 06:43 AM.

@vision

Quote:

hey always get a significant performance improvement.

Which is not surprising at all. x86 vs x86_64 is a lot more than merely 32 bits vs 64 bits. With x86_64, you get, guaranteed

* 8 extra registers. Priceless!
* byte/word/long access to *all* registers (priceless for 68k JIT)
* SSE2 register based FPU. No more x87 stack nonsense

For 68k emulations, there is, however, one actual benefit of extending the processing size to 64 bits. x86 shifts and rotates are defined to use the lower FIVE bits of the shift/rotate count, and ignore any higher bits. 68k shifts/rotates, on the other hand, are defined to use the lower SIX bits. Thus, a count of 32 would be treated as "0" on x86, but as "32" on 68k. Which causes the need for quite a bit of extra (generated) code if the JIT compiler can't prove that the extra bit is zero.
With x86_64, six bit shitf/rotate counts become available (required due to the wider data). So considerably easier generated code should be possible --- improving the ever popular RC5 "benchmark" :)

@umisef: you can still use the x87 FPU on x64. It's deprecated, in favor of SSE2, but if you want you can use it. It still makes sense for scientific application which require a better precision than the double one, or for emulating the 68K FPU with the extended precision.

Good point regarding the shifting: it can help a lot a 68K emulation / JITing.