pouët.net

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

I wholeheartedly agree.

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.

What were you doing in a friends PC?

... or any other experienced coder.

>>p.s. My child dream was speed and not
>>size optimization. But doing it on PCs???
>>Blah :P

What do you mean?

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...

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 :)

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?

>>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.

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 ? :)

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.

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. :)

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>

FoolMan LOL Thats just too funny : )

stefan - 1
optimus - 0

2 days struggling with win2k? for christ sake HOW!? (it took me 20 minutes to install)

"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..

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 :)

And I still haven't an answer why compressed/uncompressed files or the same ones renamed could give speed boost..

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.

@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.

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

intrinstic: that sounds quite interesting.
anyway, similar things always happened (ok of course not 10x difference) in pure DOS too...