Speed Comparison Program Idea Project
Blitz3D Forums/Blitz3D Beginners Area/Speed Comparison Program Idea Project
| ||
| This is something I have been kicking around in my head awhile and thought it *might* be useful / fun / interesting: It's a spinoff of Syntax's thread on super tips and basically any message in the forums dealing with speed issues. * So what is it ? Well sirs, how about a 'simple' program that everyone can add to that will grow into in all encompassing assembly of various speed test no matter how small or big they might seem. * The way it works: Start off by writing a program to compare two or more ways of doing something and have the program output the resulting times. It doesn't matter who starts the program but any additions *have* to then added to the program and the updated version is put back in the forum. The structure of this program starts with a menu of possible speed tests. Select that item and a second menu appears with various ways of doing the same thing. Any newbie or codewizard can copy/paste the program and visually test various concepts and see the results themself. In turn, maybe somebody has yet another approach that is even faster and they add their findings to the program. As we all now, when it comes to programming, there is more than one way to skin a cat. I believe the initial concept is a good idea and would answer many questions on optimization issues. I also believe that the whole thing could get real messy real quick -OR- the whole thing may not get started at all. Like I said, it is just a 'fun' little idea I have kicked around and now i have kicked it upon the forum here for others to kick around, stomp on, mutilate and thus tell me either I am a complete loon or that there is indeed some sort of merit. If interested, please respond to any of the following: 1) your views on the matter. 2) propose a mandatory outline of the program's specifications on how it should all come together / work 3) post some speed related questions 4) post some small code tidbits of things you come across 5) tell the good ol' doctor here that he really is a loon and off with his silly nonsensical proposal. 6) anything under the sun.. thoughts anyone ? some examples at the top of my head: ...Blitz Arrays vs Dim Arrays vs Banks Vs ???... ...Gosubs Vs Functions Vs ???... ...Repeat_Until vs While_Wend vs For_Next vs ???... Get the idea ? Good! Now remember, it doesn't really matter how well known the situation is, cause not everyone is up to date on the "well known" especially newbies. We take a lot for granted sometimes on the basics. Do you remember your first programs ? How would you re-implement the same concepts if you knew then what you know now ? Apply that thought to today. * In closing: What it all boils down to ( and I hope against hope ) is a interactive-quasi-programming-gems-secrets-of-gurus-code-warrior-be-all-to-end-all-ever-evolving-hunk-of-programming-knowledge. To some it would be educational, to others interesting and enlightning, and to yet to others a way to give back and help others.. for only 10 cents a day you can help a needy child... oops! Right, so flame, discuss, ignore... whatever. -ddt! |
| ||
| We've had this discussion before. http://www.blitzbasic.com/bbs/posts.php?topic=24083 >What it all boils down to ( and I hope against hope ) is a >interactive-quasi-programming-gems-secrets-of-gurus-code- >warrior-be-all-to-end-all-ever-evolving-hunk-of- >programming-knowledge. Except speedtests are subjective. What we need is a 'clever code TM (c) (R)' database, and possibly(in my case particularly, a 'Crappy code TM (c) (R)' database. Andy |
| ||
| >Except speedtests are subjective. That's one of my main gripes with the freedom of pc's. Don't get me wrong, advancing technology and free market of pc computers is great, but in a small way sucks for the programmer. In my sick twisted masochistic mind I sometimes long for the days of C64, where generally a commie was a commie was a commie. <grin> >What we need is a 'clever code TM (c) (R)' database, and >possibly(in my case particularly, a 'Crappy code TM (c) >(R)' database. Count me in on the Crappy code TM (c) ;^) Being that the test are subjective, the idea was kind of a see for yourself - your milliage may vary kind of approach as oppossed to a This is the only way to go, buck-o. True, each user will get different results, and in it's own way, this program could prove that. Expanding on that, and I see this as another not to happen idea, one could report the times and give their set-up. Still, some things are faster, no matter what. But that probally falls under Crappy coding. That could be a nice book "Game Programming Crude volumes 1 to 5" Again, this is a general concept of potential useful knowledge based all in one program even though I know I said be-all-to-end-all (Call me butter cuz I was on a roll). >A strange game. The only winning move is not to play! >How about a nice game of chess? Ah, Wargames.. cheesy but still fun |
| ||
| Dr. Delirium Tremens.... I think that is a great idea but there maybe a problem.... I am used to using the Big 'O' notation (order of magnitude)when measuring how efficient an algorithm is and was tought to apply it to almost everything. I am not sure that everyone on this forum understands that theory. If they dont, then they are going to have to learn it because this way of measuring an algorithms efficiency is standard throughout the industry. I'll certainly contribute any way I can. It is easy to measure an algorithms speed but the overheads are different and who is going to decide which is the best? It is certainly worth persuing because some of the code I have seen is horrible (including my own!). Also, some people here think that it is clever to have one long formula in a function to return a value rather than splitting it up. They dont realise that maths intensive stuff is time-consuming. People also use the Bubble Sort algorithm because the code is short. They dont realise that it is probably one of the slowest sorting algorithms ever devised with an Order of magnitude of 'O'n squared! So yes, anything to improve peoples programming skills gets my vote! Regards |
| ||
| I think this would be a great idea. I personally had a speed question in mind. What file format is rendered faster: 3ds, X, mdl, md2, md3,etc. Is one file format faster for animations and another faster for still objects like trees. These are just a few speed questions that come to mind. Not based on written code so much but on the type of object. |
| ||
| >I'll certainly contribute any way I can. It is easy to >measure an algorithms speed but the overheads are >different and who is going to decide which is the best? Basically, it's a see it with your own eyes type thing. The users doesn't see the code while the program is running, just the results and then after viewing the different approaches they can stop the program and view the listing and go from there. I know it sounds kind of dumb and at the same time time kind of cool. But it was just a thought that i wanted to share and see what others thought. If it becomes a real project in one form or another than that would be cool, if not... no big deal. I'll try not to lose too much sleep. ;^) >I think this would be a great idea. I personally had a >speed question in mind. >What file format is rendered faster: >3ds, X, mdl, md2, md3,etc. >Is one file format faster for animations and another >faster for still objects like trees. >These are just a few speed questions that come to mind. >Not based on written code so much but on the type of >object. And another idea, which goes with the program. A simple FAQ for things that are not so easy to show in the program with out having download models and graphics. The program should "create" it's own graphics as place holders. Well a got a few responses so far. Cool enough. |
| ||
| Sounds like a good idea. It would also answer quite a few question ppl post about what's faster, this or that. |
| ||
| >Sounds like a good idea. It would also answer quite a few >question ppl post about what's faster, this or that. Arghhhhhhhhhhhhhhhh(crying out of desparation!) http://www.blitzbasic.com/bbs/posts.php?topic=24083 Just because a certain procedure is faster on your development computer, it may in fact be much slower on the customers computer. We'we done this to death... Some times using a cos/sin lookuptable is faster and sometimes it is slower than using the built-in commands... In stead of a flawed list of speed comparisons, we should focus on how to make 'clever programming', which the program will benefit from on all configurations... EDIT: This should be in the FAQ. Andy |
| ||
| Andy: I did read the link. I do understand everything you said. Honest. All I am saying is sometimes there is a better way to do somethings. This is not supposed to be the final word on anything. I might add though, it isn't just clever tricks or exploits, it can be time honored functions like BubbleSort compared to QuickSort. Yes, somethings might be slower on somebody else's computer and it might even have all the bells and whistle's but it sucks eggs because my computer handles certain instances better. Once more.. I DO UNDERSTAND, and agree. The Bob guy in the other thread was stubburn. I am not Bob. ;^) >we should focus on how to make 'clever programming', which >the program will benefit from on all configurations... Yes, definately. |
| ||
| Yeah... DDT, I hear you, but I was replying to Ross C's comment above... I am sure we agree on the 'clever programming' bit... Maybe we could start by compiling a list of 'clever' questions like AbbaRue's question above, and then find the answers. Andy |
| ||
| Maybe a better idea is to start a thread for each kind of test (that would be a seperate program for each test). The first post would have the listing for the test so everyone can copy/paste it in. Have everyone run that test program on their personal system and then display the results along with their system specs in the remaining posts. This would would allow us to see which tests are affected by different setups and how much variation happens from system to system. |
| ||
| I think that including system specs of the machine on which the test was run, should be a [bold]requirement[/bold]. Providing not just speculatation, but concrete numbers to analyze and compare from various configurations. Everyone wants to know if their code will run on a "typical" end user's system. This is a good way to find out. To DDT's point, I think that seeing all of the different ways to approach a particular coding challenge offers everyone an opportunity to learn something (good and bad). Instead of just seeing one person's perspective on speed issues (per the link). It goes without saying, but I'm going to say it anyway, no one should be ridiculed/humiliated/hassled for contributing good or bad code. Let's keep this above all of that nonsense, so that everyone (noobs and code wizards) can feel comfortable with their efforts. If there are any comments to be made let's keep them constructive. This is the only way to encourage people to make an effort and contribute. Count me in! Andy |
| ||
| ;^) Thanks Andy. Okay, here's another thought. Instead of this massive program, it *could be* seperate programs, but they all would be accesible through an html file.. That might be simpler. But anyways, much like coding itself, there are probally a zillion ways we could do this too. hehe.. -DDT! |
| ||
| I also understand what is being said too. I think some ppl should be aware of this speed up. It involves hiding entities that are not in the camera's viewport. Arrow keys to move, 1 to select the normal camera, 2 to select the overhead camera to see what is being hidden. Keys 3 and 4 to switch between modes. 3 is the none hidden mode, and 4 is the hidden mode.
num_cubes=Input("How many cubes?")
Graphics3D 800,600
SetBuffer BackBuffer()
camera=CreateCamera()
camera_overhead=CreateCamera()
PositionEntity camera_overhead,0,60,0
HideEntity camera_overhead
sphere=CreateCone()
PositionEntity sphere,0,-1,0
ScaleEntity sphere,1,1,3
EntityParent camera,sphere
PositionEntity camera,0,1,0
PointEntity camera_overhead,sphere
light=CreateLight()
Type cube
Field ent
Field x#,y#,z#
Field hidden
End Type
For loop=0 To num_cubes
c.cube=New cube
c\ent=CreateCube()
c\x=Rnd(-80,80)
c\y=0
c\z=Rnd(-80,80)
PositionEntity c\ent,c\x,c\y,c\z
c\hidden=0
EntityPickMode c\ent,2
EntityColor c\ent,100,100,255
Next
mode=0;0 for none vis, 1 for vis
While Not KeyHit(1)
If KeyDown(200) Then MoveEntity sphere,0,0,0.2
If KeyDown(208) Then MoveEntity sphere,0,0,-0.2
If KeyDown(203) Then TurnEntity sphere,0,1,0
If KeyDown(205) Then TurnEntity sphere,0,-1,0
If KeyHit(2) Then
ShowEntity camera
HideEntity camera_overhead
End If
If KeyHit(3) Then
ShowEntity camera_overhead
HideEntity camera
End If
If MilliSecs()<timer+1000 Then
frame=frame+1
Else
fps=frame
frame=0
timer=MilliSecs()
End If
If KeyHit(4) Then mode=0:Gosub showall
If KeyHit(5) Then mode=1
If mode=1 Then
Gosub checkvis
End If
UpdateWorld
RenderWorld
Text 0,0,"fps="+fps+" mode="+mode
Text 0,10,"Key(3) mode 0= no hiding of entities that aren't in the cameras viewport
Text 0,20,"Key(4) mode 1= hide all entities that aren't in the camera viewport
Flip 0
Wend
End
.checkvis
For c.cube=Each cube
If EntityInView(c\ent,camera) Then
If c\hidden=1 Then
ShowEntity c\ent
c\hidden=0
End If
Else
If c\hidden=0 Then
HideEntity c\ent
c\hidden=1
End If
End If
Next
Return
.showall
For c.cube=Each cube
ShowEntity c\ent
c\hidden=0
Next
Return
|
   |