32bit/64bit

Index > Main > 32bit/64bit

Goto page Previous 1, 2, 3 Next

Author

Thread

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 23 Apr 2009, 04:23

All you told me was to read the (intel?) manual, which would probably take a month of 24/7 reading just to skim.. and "read about operating systems in general" (not even sure what that means)..

So basically whatever it is that looks in the PE to tell if it's 32bit or 64bit and set it to that mode, is prohibitively expensive to mess with during runtime?
I don't think it is, since it's easy to start over 100 blank 32bit or 64bit programs a second. And that's counting all the other stuff that runs when a process starts, to.

23 Apr 2009, 04:23

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 23 Apr 2009, 04:36

It's not windows/linux, it's the cpu itself. 64-bit Windows actually has to do more to run a 32-bit program than a 64-bit program.

23 Apr 2009, 04:36

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20448
Location: In your JS exploiting you and your system

revolution 23 Apr 2009, 04:52

Azu wrote:

All you told me was to read the (intel?) manual, which would probably take a month of 24/7 reading just to skim.. and "read about operating systems in general" (not even sure what that means)..

Please feel free to visit my website if you are unsure what an OS actually is.

Azu wrote:

So basically whatever it is that looks in the PE to tell if it's 32bit or 64bit and set it to that mode, is prohibitively expensive to mess with during runtime?
I don't think it is, since it's easy to start over 100 blank 32bit or 64bit programs a second. And that's counting all the other stuff that runs when a process starts, to.

Doing something 100 times a second is not very fast. You want to "save bloat" by dynamically switching 32/64, but in reality you would be creating a huge bloat in the OS to support such a scheme. The benefit is insignificant and the cost is enormous. The CPU was never designed to support such things. This is a large subject area, you can't expect to understand it from a few forum posts. RTFM.

Last edited by revolution on 23 Apr 2009, 05:17; edited 1 time in total

23 Apr 2009, 04:52

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 23 Apr 2009, 04:58

revolution wrote:

Azu wrote:
All you told me was to read the (intel?) manual, which would probably take a month of 24/7 reading just to skim.. and "read about operating systems in general" (not even sure what that means)..
Please feel free to visit my website if you are unsure what and OS actually is.

No, I'm unsure what you mean by replying with "lol go read about computers in general" to questions, and swearing at me repeatedly. Are you just trolling or what??

revolution wrote:

Azu wrote:
So basically whatever it is that looks in the PE to tell if it's 32bit or 64bit and set it to that mode, is prohibitively expensive to mess with during runtime?
I don't think it is, since it's easy to start over 100 blank 32bit or 64bit programs a second. And that's counting all the other stuff that runs when a process starts, to.
Doing something 100 times a second is not very fast. You want to "save bloat" by dynamically switching 32/64, but in reality you would be creating a huge bloat in the OS to support such a scheme. The benefit is insignificant and the cost is enormous. The CPU was never designed to support such things. This is a large subject area, you can't expect to understand it from a few forum posts.

Maybe YOU should read the fucking post. I didn't say I wanted to switch back and forth over and over in a tight loop. I said in certain situations having those extra registers would be useful (as in, switching to 64bit once at the beginning of said situation, and back to 32bit after).. not often..

Please stop deliberately ignoring everything I'm saying and imaginatively making stuff up to reply to. It is a huge waste of time for everyone involved.

revolution wrote:

RTFM.

Again.. which fucking manual? Stop repeating yourself already and say something useful, instead of trying to act tough.

Last edited by Azu on 23 Apr 2009, 05:24; edited 1 time in total

23 Apr 2009, 04:58

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20448
Location: In your JS exploiting you and your system

revolution 23 Apr 2009, 05:23

Azu wrote:

... and swearing at me. Are you just trolling or what??

Looks to me like you are the one doing the swearing.

Azu wrote:

Again.. which fucking manual? Stop repeating yourself and say something useful, instead of trying to be a smartass.

Intel and AMD both describe the 64/32 thing. And they do it very well. I though I already mentioned that somewhere previously? Whoops, sorry, looks like I repeated myself. But how else to answer you when you keep asking the same questions over and over again?

23 Apr 2009, 05:23

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 23 Apr 2009, 05:26

revolution wrote:

Azu wrote:
... and swearing at me. Are you just trolling or what??
Looks to me like you are the one doing the swearing.

Um no? You keep telling me to "read the fucking manual" but won't even say which one??? I asked if you meant the Intel manual, but you just replied with "read the fucking manual." again without answering.. great help.

revolution wrote:

Intel and AMD both describe the 64/32 thing. And they do it very well. I though I already mentioned that somewhere previously? Whoops, sorry, looks like I repeated myself. But how else to answer you when you keep asking the same questions over and over again?

Are you honestly talking this shit with a straight face? I've had enough of your immaturity. Just go away already.

Last edited by Azu on 23 Apr 2009, 05:28; edited 1 time in total

23 Apr 2009, 05:26

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20448
Location: In your JS exploiting you and your system

revolution 23 Apr 2009, 05:28

Umm, at the risk of repeating my self yet again: "Intel and AMD both describe the 64/32 thing."

Hmm, this is getting boring now. It was fun for a while, but now I have no interest anymore.

23 Apr 2009, 05:28

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 23 Apr 2009, 11:30

Azu, this article (written by me) should help you to get familiar with Intel manuals:

x86-64 Tour of Intel Manuals

And you insulted revolution for no reason, he just kept trying to answer your repeated question.

We don't know why Intel/AMD designed their procesor in the way they did, but we can suggest googling or refer you to procesor manuals which answer your questions. So asking, fo example, why 32<->64-bit switch requires ring0 is useless because it was hardwired this way. That's all.

EDIT: link fixed

Last edited by MazeGen on 24 Apr 2009, 10:33; edited 1 time in total

23 Apr 2009, 11:30

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 23 Apr 2009, 16:01

MazeGen wrote:

Azu, this article (written by me) should help you to get familiar with Intel manuals:

x86-64 Tour of Intel Manuals

Thank you. I guess my browser just hates me or something. Says page not found. Confused

MazeGen wrote:

And you insulted revolution for no reason, he just kept trying to answer your repeated question.

By swearing at me and telling me to read "the fucking manuals about amd/intel" over and over?

How would you like it if you asked how to change the oil in your car and I just told you to "read all the fucking manuals about automobiles" over and over, and demanded an explanation for why you wanted to change the oil?

MazeGen wrote:

We don't know why Intel/AMD designed their procesor in the way they did, but we can suggest googling or refer you to procesor manuals which answer your questions. So asking, fo example, why 32<->64-bit switch requires ring0 is useless because it was hardwired this way. That's all.

I was just curious. He insisted it was by design so I thought he knew the reason.

23 Apr 2009, 16:01

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 23 Apr 2009, 16:31

Don't get so worked up, Azu, just remove the " from the end of the URL. Peace!

23 Apr 2009, 16:31

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 23 Apr 2009, 23:48

An application doesn't select the mode it starts on, it's the OS that chooses whether to load native 64bit or 32bit compatibility depending on the PE type.

I guess that theoretically you could change mode of a running task, but the code to do so isn't super-simple, and it's expensive enough to make it useless for your task. And the OS code to support it would be very very complex, to the point that nobody should bother with it.

Do native 64bit if you can get an advantage from it, and don't lose sleep over the slightly larger code size.

23 Apr 2009, 23:48

r22

Joined: 27 Dec 2004
Posts: 805

r22 24 Apr 2009, 18:25

Just fork your program into two programs/peices.

32bit Version with your regular code
64bit Version with JUST your optimized code

Have both programs communicate with eachother over UDP or TCP SOCKETs and your good to go.

32bit Guy:
- Starts 64bit Guy
- Regular/General 32bit program/code
- SOCKET Client to send requests to 64bit Guy

64bit Guy:
- Optimized 64bit program/code
- SOCKET Server to accept requests from 32bit Guy

Can't beleive no one suggested this.

24 Apr 2009, 18:25

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 24 Apr 2009, 18:36

Great idea! I think that's how I'll do it. Thank you.

24 Apr 2009, 18:36

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 24 Apr 2009, 18:37

r22: probably because it has so much overhead that it likely isn't worthwhile? And splitting into two programs (and adding all the sync stuff!) you end up with more code than a single x64 apps, so what's the point?

Slower AND bigger than a single x64 executable...

24 Apr 2009, 18:37

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 24 Apr 2009, 18:47

I don't think he meant a full version of each lol.

24 Apr 2009, 18:47

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 24 Apr 2009, 18:51

Azu: of course he didn't, but you do end up with two executable, and the additional overhead of socket communication (memory mapped files would be faster, but still requires synchronization). Synchronization itself can be quite a performance bottleneck, and if you need to send data back & forth via sockets that will kill performance.

And memory usage will most likely be higher with two processes, unless your main application is large (think of all the behind-the-scenes stuff that goes into each process).

24 Apr 2009, 18:51

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 24 Apr 2009, 18:56

Quote:

Can't beleive no one suggested this.

I was about to suggest the following: shared memory + synchronization elements, but since Azu haven't said what he was needing to do in 64-bit I've decided to not say anything because doing this to execute few 64-bit instructions is a huge overhead (less than with sockets but yet very high overhead).

I'll see if I have time this weekend to implement this on Linux since I have 64-bit there.

24 Apr 2009, 18:56

r22

Joined: 27 Dec 2004
Posts: 805

r22 24 Apr 2009, 20:55

A simple socket client / server isn't really that much overhead.
Although the performance hit from the socket communication (even though it's local) might be substantial.

But if he's running an ~hour long calculation in 64bit from his 32bit app then the SOCKET delay is negligible compared to the optimization improvement from the 64bit code.

So like everything it depends on the situation.

24 Apr 2009, 20:55

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 25 Apr 2009, 01:15

LocoDelAssembly wrote:

Quote:

Can't beleive no one suggested this.

I was about to suggest the following: shared memory + synchronization elements, but since Azu haven't said what he was needing to do in 64-bit I've decided to not say anything because doing this to execute few 64-bit instructions is a huge overhead (less than with sockets but yet very high overhead).

I'll see if I have time this weekend to implement this on Linux since I have 64-bit there.

Every once in a while I need to do a very heavy calculation, and the extra registers help a lot, so the overhead isn't that bad. I will try to get it working with shared memory though.. that should be even better.

25 Apr 2009, 01:15

kalambong

Joined: 08 Nov 2008
Posts: 165

kalambong 25 Apr 2009, 04:55

revolution wrote:

Azu wrote:
All you told me was to read the (intel?) manual, which would probably take a month of 24/7 reading just to skim.. and "read about operating systems in general" (not even sure what that means)..
Please feel free to visit my website if you are unsure what an OS

Umm... to make sure I fully understand, would you kindly attach your website address so I can pay a visit?

25 Apr 2009, 04:55

Goto page Previous 1, 2, 3 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum