If I where to make a demo in VB...
category: general [glöplog]
isn't there any pouet bot that would kick users when they flood the bbs, like on irc?
an ignore function would be appreciated as well
An a bot that prints "RTFM" in really big letters when someone asks something like "what is a runtime library?".
yes it would.
Either that or a nice new database section for qbasic tutorials?
Lemme put some pepper. I'd say i'm against visual basic. I heard that it's still half-bytecode. Heard that it's not nearly as fast at number crunching as really compiled languages. But it's just rumors. Now, since a gap between Delphi and C++ is really not that big, you might want to try using Delphi! The Delphi Jedi maintain good DirectX and OpenGL ports. You might need to write your own imports for OpenGL extensions, but it's not hard. I'd say DirectX might be preferable under Delphi. Just beware: if you start your 3D app from any Borland IDE, acceleration is disabled or your app will crash because it conflicts with a debugger - thus you must start your apps from outside IDE to check them for speed.
Yet another thing: if you keep your code simple and let the underlying library (DirectX/OpenGL) do stuff, even a bytecode language might make no difference.
Java is fast enough at number crunching, but it wastes a lot of memory and may thus make demos slow. The situation seems to improve iin leaps in the latest releases though. And besides, the shim between Java and the underlying library is *slow*.
Optimus: I'll try to explain why compilers take up such huge amounts of space. Try to download LCC. It is a tiny download - but when it installs it makes linker "stub" libraries for many system DLLs, and that makes 12 meg out of 2. (or something alike). I believe if they were generated at application compile time, the linker would become slower.
Another thing that takes up major space is that all compiled code in the development environments is annotated with Debug Information - source file line numbers, variable names and stack placements, and so on. This makes the code about 4 times bigger than it would be without.
You must also consider documentation - which is usually multiple dozen megs of help files. Windows API alone is 15 meg.
Then there is a lot of code you would never use, and a lot of code which enables you to handle graphic elements visually in the IDE.
I'm not at home now, but i'd also be interested to put the IDEs i have apart and tell you what makes up their size.
-eye
Yet another thing: if you keep your code simple and let the underlying library (DirectX/OpenGL) do stuff, even a bytecode language might make no difference.
Java is fast enough at number crunching, but it wastes a lot of memory and may thus make demos slow. The situation seems to improve iin leaps in the latest releases though. And besides, the shim between Java and the underlying library is *slow*.
Optimus: I'll try to explain why compilers take up such huge amounts of space. Try to download LCC. It is a tiny download - but when it installs it makes linker "stub" libraries for many system DLLs, and that makes 12 meg out of 2. (or something alike). I believe if they were generated at application compile time, the linker would become slower.
Another thing that takes up major space is that all compiled code in the development environments is annotated with Debug Information - source file line numbers, variable names and stack placements, and so on. This makes the code about 4 times bigger than it would be without.
You must also consider documentation - which is usually multiple dozen megs of help files. Windows API alone is 15 meg.
Then there is a lot of code you would never use, and a lot of code which enables you to handle graphic elements visually in the IDE.
I'm not at home now, but i'd also be interested to put the IDEs i have apart and tell you what makes up their size.
-eye
That's what I got from the quickbasic forum:
http://www.neozones.com/Board/Messages/48865.shtml
BC with the switch /A gives you an assembly listing of the code. That's also an interesting switch for me, to see how Quickbasic compiles. Didn't knew it, since I always compile automatically from inside the IDE.
http://www.neozones.com/Board/Messages/48865.shtml
BC with the switch /A gives you an assembly listing of the code. That's also an interesting switch for me, to see how Quickbasic compiles. Didn't knew it, since I always compile automatically from inside the IDE.
I still don't like big compilers. I don't need these megabytes of libs and stuff, just few simple stuff. And still, I believe some of these could fit in a much fewer space..
In the 90ies, I made a program that weighs and loads materials to make concrete in an industrial environment (Yes, it was making _really_ large machines work). It was rather large but it worked, and it was quite smart too. I did that in QB45 and it worked on 286/386 computers. When sometime after I re-wrote it on Borland Pascal, it run at least at double speed. Not to mention that I could read it alot better and I was able to do stuff that I couldn't with QB45. Oh, and on a side-note, BP6 was only 1 1.44 disk.
That tells me that either QB is interpreted, or its 'runtime library' sucks. Anyway, I never did anything else on QB after that, seeing how childish it was.
That tells me that either QB is interpreted, or its 'runtime library' sucks. Anyway, I never did anything else on QB after that, seeing how childish it was.
DISCLAIMER: What you are about to read may be hazardous to your physical and / or mental health. Proceed at your own risk. The author has no responsibility of any damages done to your body / brain because of this. You have been warned.
Quick Basic 4.5 source:
Turbo Pascal 5.5 source:
Great effort has been made so that both programs (bubble-sorts) are as similar as possible. They were compiled as .EXE files and ran at a P4 2.4 with Windows 2000 using Realtime priority. The results:
qb45_bub.exe: 26,828 bytes, 14.5 seconds
tp55_bub.exe: 2,368 bytes, 11 seconds
Verdict: The quick basic program took 32% more time to run, its executable was 1033% bigger in size and the source code looks like crap. So that's why I switched to pascal... hmmm.
Notes: You are free to to the test on your own machine and share the results. Also, you can expect that a turbo C 2.0 program would be slightly faster than pascal, although alot bigger in size.
/me runs like hell
Quick Basic 4.5 source:
Code:
DIM size
size = 31000
DIM t%(size)
DIM c%
DIM o%
DIM w%
FOR c% = 1 TO size
t%(c%) = c%
IF ((c% MOD 2) = 1) THEN t%(c%) = (c% * -1)
NEXT c%
FOR c% = size TO 2 STEP -1
FOR o% = 2 TO c%
IF (t%(o%) < t%(o% - 1)) THEN
w% = t%(o%)
t%(o%) = t%(o% - 1)
t%(o% - 1) = w%
END IF
NEXT o%
NEXT c%
FOR c% = 1 TO size
PRINT t%(c%)
NEXT c%
Turbo Pascal 5.5 source:
Code:
program tp55_bubble;
const
size = 31000;
var
t : array [1..size] of integer;
c : integer;
o : integer;
w : integer;
begin
for c:=1 to size do begin
t[c] := c;
if ((c mod 2) = 1) then
t[c] := (c * -1);
end;
for c:=size downto 2 do begin
for o:=2 to c do begin
if (t[o] < t[o - 1]) then begin
w := t[o];
t[o] := t[o - 1];
t[o - 1] := w;
end;
end;
end;
for c:=1 to size do begin
writeln (t[c]);
end;
end.
Great effort has been made so that both programs (bubble-sorts) are as similar as possible. They were compiled as .EXE files and ran at a P4 2.4 with Windows 2000 using Realtime priority. The results:
qb45_bub.exe: 26,828 bytes, 14.5 seconds
tp55_bub.exe: 2,368 bytes, 11 seconds
Verdict: The quick basic program took 32% more time to run, its executable was 1033% bigger in size and the source code looks like crap. So that's why I switched to pascal... hmmm.
Notes: You are free to to the test on your own machine and share the results. Also, you can expect that a turbo C 2.0 program would be slightly faster than pascal, although alot bigger in size.
/me runs like hell
Sorry for not answering. Your greek comment was funny :)
Yes, yes, yes,. you have won! I haven't compiled it because I am bored to install BC (if I have it in my CDs I got with me) but I know it must be definitelly faster than Quickbasic. (Not that much as I see though, thanks for the benchmark ;) But that wasn't my point anyways..
Pascal is faster and produces much smaller executable than Quickbasic, are you sattisfied now?
P.S. I 'd always like to test some routines in Pascal too, but never found the time to do so. Perhaps I should look at my CDs..
Yes, yes, yes,. you have won! I haven't compiled it because I am bored to install BC (if I have it in my CDs I got with me) but I know it must be definitelly faster than Quickbasic. (Not that much as I see though, thanks for the benchmark ;) But that wasn't my point anyways..
Pascal is faster and produces much smaller executable than Quickbasic, are you sattisfied now?
P.S. I 'd always like to test some routines in Pascal too, but never found the time to do so. Perhaps I should look at my CDs..
BC=BP
Yesterday I discovered that my HD was full. I searched immediatelly for the reason by using Windows (total) Commander. A great tool, one of it's great features beeing that you can check the total size of a directory tree by pressing Space. I found out that an important ammount of HD space was eaten from the bloody IDEs/SDKs I downloaded in my USB memory stick in order to try. C/C++ compilers, DirectX SDK, Java IDEs and interpreters and more. Each of them took tens of MBs! If I have to install every shit of it in my PC, and if they are not so sexy fitting in one disc like Quickbasic is, then scheisse!
Shit inside, as we say in Greece :)
Also, one of them, IDE for Java NetBeans something, was crawling!!! 64MB of memory was very few for it :P
Suxx,. I found another IDE called JOE, which is slick. It compiles, ok, but I don't know where should I put some classes (Prog1Tools are called) in order to compile some programm. Anyone help?
Also,. I really really really don't fuckin understand why these so bloated compilers take so much time to compile even a simple helloworld programm? Sometimes, the HD doesn't work, but it is still waiting. As it was a CPU intensive calculation or something :P
Why in quickbasic, even a big programm, compiles in 1-2 seconds but in modern compilers even the shittiest thing makes the HD to worry (grrrrour, grrrouurr, grougrougrougrougrourrr) and the CPU to wait? This one, I can't understnad! And don't tell me a reason, because there can't be any reason for such a simple shit :P
So,. yes, some percent speed, some percent executable size, but some persent better for size of compiler and compiling time, when talking about quickbasic =)
Shit inside, as we say in Greece :)
Also, one of them, IDE for Java NetBeans something, was crawling!!! 64MB of memory was very few for it :P
Suxx,. I found another IDE called JOE, which is slick. It compiles, ok, but I don't know where should I put some classes (Prog1Tools are called) in order to compile some programm. Anyone help?
Also,. I really really really don't fuckin understand why these so bloated compilers take so much time to compile even a simple helloworld programm? Sometimes, the HD doesn't work, but it is still waiting. As it was a CPU intensive calculation or something :P
Why in quickbasic, even a big programm, compiles in 1-2 seconds but in modern compilers even the shittiest thing makes the HD to worry (grrrrour, grrrouurr, grougrougrougrougrourrr) and the CPU to wait? This one, I can't understnad! And don't tell me a reason, because there can't be any reason for such a simple shit :P
So,. yes, some percent speed, some percent executable size, but some persent better for size of compiler and compiling time, when talking about quickbasic =)