pouët.net

Go to bottom

Sucky PCs

category: general [glöplog]

They say that the bg_yeah 64b entry runs faster if it's not extracted. And I had managed to run it in an incredible 10Xspeed that makes it unviewable and then it runs ok in the 2Ghz machine here. Wicked stuff!

Someone told me "I realized that sometimes if I rename my .com file, its speed changes..."

I have noticed that too. If I rename the batch file which runs ffix.com and then my quickbasic demo Deedlines Sax, then I get speed diferrences. If I load EMS or XMS, the results are exactly the opposite!

A programm which outputs fast (almost) in vram and tells me fps, after running fastvid, sometimes it displays 154fps and sometimes 276fps (but that's because of the sucky motherboard).

Of course some intros run slowers in modern machines, like a blurzoom/feedback effect which manage to go faster enough in a Pentium1 and crowls in an Athlon(!).

Or Tube. I was in a friend's PC and we manage to run Tube faster in VirtualPC emulator rather than in the real and same PC!!! =)))

I know that the last examples must be something about branch prediction and such shit of modern CPUs, also they say that you can't count cycles (something very sad) after 386.

But that thing about changing speed whether you decompress or not (and so big diferrece?) or little speed changes depending on the name of your file?!

How and why does this happen?! It's either technically interesting for me or I am just very curious because this is the most crazy thing ever. I'll have to discuss wicked PC coder's stories with my friends when I come back in Greece! :P

p.s. My child dream was speed and not size optimization. But doing it on PCs??? Blah :P
added on the 2004-03-03 15:44:22 by Optimus Optimus
I wholeheartedly agree.
added on the 2004-03-03 16:02:20 by sagacity sagacity
i think it's something about os because modern processors can render tube so fast that you will only see some shit instead of amazing tunnel effect ( greets to baze anyway :). So i think os delays opcode execution of com files. That's just a guess so i may be entirely wrong. I'd like to hear something from ryg or kb.
added on the 2004-03-03 16:28:16 by apricot apricot
What were you doing in a friends PC?
added on the 2004-03-03 16:28:18 by gammawave gammawave
... or any other experienced coder.
added on the 2004-03-03 16:29:13 by apricot apricot
>>p.s. My child dream was speed and not
>>size optimization. But doing it on PCs???
>>Blah :P

What do you mean?
added on the 2004-03-03 16:39:38 by uutee uutee
gammawave: maybe he was trying to cool down the cpu with his breath... :)))

anyways PCs suck. they really do. but so do we... so it sounds a fair deal...
added on the 2004-03-03 16:54:29 by FooLman FooLman
if you think that what happens in a dosbox has anything to do with normal program execution speed on current machines, i guess no one can help you :)
added on the 2004-03-03 17:06:40 by ryg ryg
Speed optimizing a PC stinks. I just stick to size optimizing, since I get nice, objective results. Besides, who needs speed when the video card is maxed out anyhow?
added on the 2004-03-03 17:32:24 by s_tec s_tec
>>Besides, who needs speed when the
>>video card is maxed out anyhow?

So you can throw polygons around the screen pretty fast. But remember that sending the stuff to screen is just part of the story.
added on the 2004-03-03 17:43:12 by uutee uutee
actually i was sure about os but the question is why intros run with different speed on similar MS oses ( am i right, optimus ? maybe your local crackers add some code to m$ products before releasing them ? :)
added on the 2004-03-03 18:31:31 by apricot apricot
Up to the Pentium you can count cycles easily.
Pentium Pro - III is a bit more complicated, but in most cases it help to count things you should not do (partial register stalls). Vtune does also a good job..

Pentium IV otoh is quite unpredictable, but still there are certain rules and if you know and think about the cache there is no magic there.
added on the 2004-03-03 19:55:48 by Stelthzje Stelthzje
If you want speed optimization, come to C64! There you have excactly 19,656 cycles/frame = 982,800 cycles/sec, or almost a megahertz! The only things that can steal cycles from you is badlines and sprites, but that's all very (kinda) predictable and logical. Well, for Crossbow/Crest atleast. :)
added on the 2004-03-03 20:07:05 by cruzer cruzer
where is my Amiga! those pc sucks, and windows2000 more! (i try to install this crap from 2 days)
I also find it very odd that some C64 demos runs slower on PC than on a C64 , or might even not look correct.. Its like.. WEIRD i mean... PC is like fast..

</optimus logic>
added on the 2004-03-03 20:32:39 by Hatikvah Hatikvah
FoolMan LOL Thats just too funny : )
added on the 2004-03-04 04:37:17 by Mike 3D Mike 3D
stefan - 1
optimus - 0
added on the 2004-03-04 07:54:22 by gloom gloom
2 days struggling with win2k? for christ sake HOW!? (it took me 20 minutes to install)
added on the 2004-03-04 10:17:19 by okkie okkie
"I also find it very odd that some C64 demos runs slower on PC than on a C64 , or might even not look correct.. Its like.. WEIRD i mean... PC is like fast..

</optimus logic>"

No, no, no! I said that we managed the opposite. To run something faster in an emulator than in the real PC..
added on the 2004-03-04 12:03:12 by Optimus Optimus
Cruzer: What happened with your C64 programming tutorial at C64.CH? However, I don't need it now because I started programming in C64 too by reading some other tutorials..

I have a real C64 now (but in Greece, not here in Germany) and I already started coding something. 6510 looks much easier and elegant than Z80, I luv programming on C64 very much :) I am planning to finish a 4kb C64 intro for Breakpoint, if I manage to be there anyways.

And yes, I count directly every cycle on the CPC, same can happen with C64 and other old machines, but these diferrences in cycles with bad lines and sprites are kinda wicked (someone had explained me though), we never had such stuff on the CPC :)
added on the 2004-03-04 12:07:45 by Optimus Optimus
And I still haven't an answer why compressed/uncompressed files or the same ones renamed could give speed boost..
added on the 2004-03-06 16:25:00 by Optimus Optimus
Optimus: I'm no expert at the subject, but I'd say that you're mostly imaging it.

When you're going at around 154-217 fps, there's really quite a bit of uncertainity going around.

Try running some newer demos that require better hardware and run at around 20fps. That's when the timers gets more stable and adjusting your feng shui furniture positions shouldn't affect the fps anymore.
added on the 2004-03-06 18:05:25 by uutee uutee
@Optimus
Try the following
where you have the bg_yeah.zip archive located, make a folder called "test.test" and place the yeah.com file in there. Now run it, and you'll see that it runs at hyper speed as if you were running it from the archive.
I can only guess it's an undocumented feature of ntvdm. Having a full stop "." within a directory name kicks in the hyper speed for non PE and MZ formats.
Doing this on "normal" win32 based execs makes no difference in speed. For example i tested quickly with fr-025 and still got the same benchmark result of 38500 @ 1024x768.
Someone will have to check if it works like this under Win9x.
Tests with WinExec and CreateProcess make no difference. And these days WinExec goes through CreateProcess anyways i think.
Interesting anyways, maybe if i get time i might trace through ntvdm and see if there is anything obvious about why this happens.
And, i did reach a point with testing different directory names that no matter what i did, it reverted to the normal slow speed. But if you reboot the machine, you can go back into hyper mode.
added on the 2004-03-06 20:11:25 by Intrinsic Intrinsic
guess it's the cache. cache is always to blame :)
i had (have?) similar problems, for example my last 256b runs much faster on a 700mhz celeron than on a 2ghz athlon xp :(

in the good old 486 times even the cache was easier to understand. for example a very standard bitmap-rotator rutin is much faster at degrees 0 and 180 than at 90 and 270, since in the first case the memory is accessed horizontally while in the second case vertically

but these new processors are very hard to understand; and in 256b you can't simply align everything
added on the 2004-03-06 20:17:21 by blala blala
intrinstic: that sounds quite interesting.
anyway, similar things always happened (ok of course not 10x difference) in pure DOS too...
added on the 2004-03-06 20:19:15 by blala blala

login

Go to top