bsnes upx'd?
bsnes upx'd?
This message is for byuu and I post here because I'm too lazy to search a bsnes forum and register.
byuu don't upx bsnes
an upx'd application performances are much lower than a raw binary.
if you need to lower bw usage, use 7zip
<!-- end of rant -->
byuu don't upx bsnes
an upx'd application performances are much lower than a raw binary.
if you need to lower bw usage, use 7zip
<!-- end of rant -->
Use: "upx -d bsnes.exe"
Bandwidth costs money, and UPX+ZIP saves bandwidth.
Meanwhile, anyone with a PC that can get even ~5fps with bsnes will open the program instantaneously -- making the compression irrelevent. Performace after startup decompression is identical.
I'm not going to require users to download 7zip. Every copy of Windows sans the 9x series it won't run on, comes with built-in ZIP decompression.
Bandwidth costs money, and UPX+ZIP saves bandwidth.
Meanwhile, anyone with a PC that can get even ~5fps with bsnes will open the program instantaneously -- making the compression irrelevent. Performace after startup decompression is identical.
I'm not going to require users to download 7zip. Every copy of Windows sans the 9x series it won't run on, comes with built-in ZIP decompression.
You mean 6.2MB instead of 6.0MB? :/That's incorrect, it will eat up much more memory than a raw binary during the whole use.
A lot less people have 7zip decompressors than zip decompressors ... that's the main problem with that.Besides I think a 7zipped binary could possibly be smaller than upx+zip.
You probably have a cache problem.byuu wrote:You mean 6.2MB instead of 6.0MB? :/
My testing while running FF4J (v1.0).
upx'd

raw

22.1 MiB vs 4.7 MiB
And the gap will increase as the application grow bigger.
For MAME binaries, memory usage is far above 100MBytes.
Increasing the memory usage has a direct effect on performance. The more memory, the slower.pagefault wrote:UPX doesn't make it perform slower, it just increases the memory usage
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Only when you don't have that memory in the system. Otherwise it has no effect at all on performance. To demonstrate you can make a hello world app and malloc 2gb of ram to it, it's not going to run any slower just because it's using more memory, provided you have that much in your system.Y~K wrote:Increasing the memory usage has a direct effect on performance. The more memory, the slower.
Watering ur plants.
With Star Ocean loaded, played up to the name select screen:

And for what it's worth, something is wrong with your task manager. bsnes.exe consumes ~14.5MB upon initial load with no games open. ~4.5MB is impossible ... I don't care what your task manager says. There are lookup tables between the S-PPU and memory bus alone that total more than that. They are constructed immediately upon startup, rather than during each game load.
However, if UPX really consumed ~15MB of extra memory, I actually would remove it. But that is not the case. It only consumes extra memory worth the size of the compressed executable. This is because the compressed binary itself is loaded by Windows into an address space that cannot be written to by the UPX decompressor (0x401000+)
... and even if it could, it would require copying the decompressed program right on top of that data again (since you have to decompress to a separate buffer than your compressed one for obvious reasons), which would be slower and pointless.

And for what it's worth, something is wrong with your task manager. bsnes.exe consumes ~14.5MB upon initial load with no games open. ~4.5MB is impossible ... I don't care what your task manager says. There are lookup tables between the S-PPU and memory bus alone that total more than that. They are constructed immediately upon startup, rather than during each game load.
Precisely.Only when you don't have that memory in the system. Otherwise it has no effect at all on performance.
However, if UPX really consumed ~15MB of extra memory, I actually would remove it. But that is not the case. It only consumes extra memory worth the size of the compressed executable. This is because the compressed binary itself is loaded by Windows into an address space that cannot be written to by the UPX decompressor (0x401000+)
... and even if it could, it would require copying the decompressed program right on top of that data again (since you have to decompress to a separate buffer than your compressed one for obvious reasons), which would be slower and pointless.
couldn't this easily be solved by offering both?
in other words
bsnes (same as before)
bsnes source
and
bsnes 7z
would this really be a problem? it wouldn't cost you any more bandwidth.
in other words
bsnes (same as before)
bsnes source
and
bsnes 7z
would this really be a problem? it wouldn't cost you any more bandwidth.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
It would require more storage space (I only have ~2-5MB) and would take more of my time. But it wouldn't eat up much more bandwidth ... really, only a few people (and bots) would fetch both.Panzer88 wrote:couldn't this easily be solved by offering both?
...
would this really be a problem? it wouldn't cost you any more bandwidth.
But then, it's not a problem in the first place.
Y~K runs a 1MB ROM, on an emulator that uses ~800kb for the executable, 2MB for the S-PPU lighting tables, 2MB for the video output surface, ~512kb for the video output color lookup tables, ~256kb for the bus memory indexing tables, 128k for CPU WRAM, 64k for PPU VRAM, 64k for APU RAM, not to mention the rest of the code's allocations, and his explorer reports that bsnes is only using ~4.7MB of memory ... yet he wants me to believe that the problem is with my computer's caching ... :/
It's only affecting him, and he said he would upx -d the executable. That will in turn save me a lot of time per release, so we'll go with that. Further, it's actually been tested by a few people before ... applications actually start up faster with UPX on modern PCs, because loading a smaller amount from disk and decompressing is faster than loading a larger amount from disk.
Sorry, Y~K, I do value your input, so I don't mean to seem rude about the issue. But you do have an easy workaround, so ...
Last edited by byuu on Tue Jan 15, 2008 1:02 am, edited 2 times in total.
-
- Inmate
- Posts: 1751
- Joined: Mon Dec 06, 2004 7:47 am
- Location: WA
it can be solved by ignoring it, since it has been shown to be a non-issue.
i'm going to trust byuu's results with pf's backup.
even if it took that much more RAM, like they said, it shouldn't matter because it's not like bsnes is making you run out of RAM.
i'm going to trust byuu's results with pf's backup.
even if it took that much more RAM, like they said, it shouldn't matter because it's not like bsnes is making you run out of RAM.
[img]http://i26.photobucket.com/albums/c128/sweener2001/StewieSIGPIC.png[/img]
Nah, not at all. It was a good idea for a compromise. In truth, if I had lots of bandwidth, or an SF account or something, I wouldn't mind sticking the raw EXE in a ZIP file to begin with. Or offer two separate files. It only adds ~200kb onto the ZIP file.Panzer88 wrote:didn't mean to come across as untrusting, I just like to look for win-win situations but it doesn't really bother me either way.
what makes you think us have the problem?Y~K wrote:about bsnes I tested again and still got the same result, you may have a cache problem. no problem thought, I now have a copy of upx in my bsnes folder and I will live with decompressing myself every update.
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
Stupid moving parts slowing our machines down. T_Tbyuu wrote:[... applications actually start up faster with UPX on modern PCs, because loading a smaller amount from disk and decompressing is faster than loading a larger amount from disk.
Athlon XP 2800+
765MB DDR-333
AGP Geforce 6200
Took me, what, a year to update this info?
And meh, screw legs.
Oh... puns. I get it. Shame on me.
765MB DDR-333
AGP Geforce 6200
Took me, what, a year to update this info?
And meh, screw legs.
Oh... puns. I get it. Shame on me.
I too think program-level compression is stupid (since it prevents the OS from doing intelligent things with paging a program in), but since the end-user can un-upx a program, I agree that bsnes should be UPX'd. After all, if you don't like UPX, just treat it as a compression format like ZIP where you have to decompress before using. Why the hell should it be in two formats when one is sufficient?
how do you do it?blargg wrote:I too think program-level compression is stupid (since it prevents the OS from doing intelligent things with paging a program in), but since the end-user can un-upx a program, I agree that bsnes should be UPX'd. After all, if you don't like UPX, just treat it as a compression format like ZIP where you have to decompress before using. Why the hell should it be in two formats when one is sufficient?
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]