Oops, scratch what I said, its IMPOSSIBLE to bypass the standard on disk cache, as that is controlled by the DISK ITSELF

bypassing the disk buffer is impossible but putting it in contantly reading that's not and making an thing almost identical as prefetch tha's not so impossible and for the last time freebsd have a swap as all the systems but it checks the amount of ram present in the system and in case that the system have mutch ram it will not use it understood... Many things that i say could sound crazy they aren't if you have an fast disk acssess and other kinds of stuff fast more time we will reserve for other task an example: we took 90ns for reading 4 bytes on the disk and with this bytes we could process them and make some stuff.... on other way we could reas 4 bytes from the disk but these ones are slower because we took 120ns for reading them this will slow down the other tasks, and for the people that say that in games the system uses few kernel call's well you are wrong "IT IS MULTITASK OR NOT " if it then other tasks must be called and executed when i say call its only a way of saying, that tasks must be controled by the kernel that will acssess to the disk and other kinds for permanent refresh, on other and people say that MAC OS X doesn't use freebsd so i will demosntrate this for the last time this is the address www.bsd.org, another thing you should understand that UFS-FFS2 is an filesystem that read and write in both modes sync and unsinc.... well about my 16 certificates they took me long to get and about i'm one 1337 that's a certificate in case you don't know... and i'm a litle tired for trying to make me understand.... regards rayden5...

Wouldn't that difference just be because of disk seek times??

OS X is based off of a UNIX kernel, NOT FREEBSD (FreeBSD is, after all, based on BSD - so if anything OS X is based on BSD, as your link would indicate, again, NOT FREEBSD)

When playing a game you also don't likely have any other major programs running sucking up the CPU. But this is negligable anyway, as most modern games are GPU limited, not CPU (and most definitely not harddrive limited)

So please, PLEASE stop talking about FreeBSD's filesystem and harddrive performance, as that has NO IMPACT ON DOOM3'S FRAMERATES AT ALL. If you think that it does, then maybe you should get 16 more "certificates" in something a bit more relevant than '1337' sp34k

In the end, FreeBSD, Linux, OS X, Windows, et al. will run games roughly identically as fast as each other given equal hardware and drivers. Linux and FreeBSD will be even closer given that they are both running the same X system and nvidia-glx drivers (obviously the kernel driver is different, but thats not what is controlling the OpenGL acceleration)

One point you are write the code for of x is the same you forget we have to compile it for everyplatform "./configure && make && make install && make clean" did you forget this comand or, but if you think the other process have no impact why the hell the kernel changes program's at every 54ms and why the hell CPU goes till 100% on window's and why the hell we must put some dirty spaces for windows and other OS not going on 100% all the time could you explain... It is fairly simple to me games use a lot CPU althouth they use the GPU for rendering and other hard stuff 's " remenber GPU's are specified operation CPU like DSP's and CLC's and other's ", games still use the CPU for running well comon don't you think that the game code run all on the GPU that's ridiculous... not even i have the corage to say... about 1337 its not h4x0r it means elite hackers and about certificates well breack this and we will see if you are smart enouth... "WTGYU AGVSW FSSGY EESLT MIEAI OOLOS LNTED JCNNL RLAOO LCLEO UTODL EABDP TEETN SHRTB ITETL HHTCO TITHE FELHA EITAT UNWEN OTEEY RDENU SKESE RHDJI EDRFS EALOA GEAOT IESIE YBVLR ELSBN SNSNP OOEUY TEOIO AAODR UUHTO TTNSW SMOIO RTOIU RTEEB EONTG LSUOB YEOAY NNLOR OERNE IRFSE" when you could read this we will talk, another thing you don't need your PC for this its fairly simple...

Where do you get this crap? I didn't say games only run on the GPU, I said they are GPU LIMITED, as in the GPU is the bottleneck

./configure && make only compiles and links it to system libraries, it doesn't change the program code. If a program is slow, it'll be slow on ALL systems. ./configure doesn't magically change the code to be faster. The version of GCC and the optimization flags will have more of an effect than ./configure will

Face it already. FreeBSD == great for servers, but not much else. It is NOT a desktop oriented kernel, as the FreeBSD features page doesn't try to cover up. Windows XP will pwn FreeBSD and linux hands down in games. FreeBSD is not god's gift to computers.

are you crazy that tree comands are part of the GNU they will compile an source to an program not only link the program to its libraries, if that happens in that way why the hell we will need of the source... and about the games they are not only GPU limited i have interpreted that you have said that they only use the GPU for executing... that's not true as the CPU is the most affected.... And you have forget that i have an changed FreeBsd i was saying this form beginning and you aren't realy getting the idea 6.2 alpha test version says something to you...

Are you an idiot? I'm asking that seriously now.... All the configure script does is check for necessary libraries, generate the Makefile to link against those libraries, and as a way to disable/enable features in the form of #define's. Thats what ./configure does. It is "make" that actually builds it and links the program - although surely a 1337 FreeBSD developer with 16 certificates would know that



Modern games are GPU limited. If you disagree with this statement, then I ask once more - are you an idiot? The FreeBSD version you have is irrelevant, as it still won't change anything relevant.

I agree much with Kllrnohj here. I have little Linux experiance, and a lot of mine is precompiled stuff, but I have a rough idea what ./configure, make, and make install do.

i will tell you one thing create an asm program for freebsd and one for linux and you will see the diferences and make does not only link the libraries it compiles the prpogram check the freesoftware foundation and you will see that programs of GNU are source destributed nothing comiled, another thing is games are not GPU limited they execute almost their code on the CPU, GPU only does rendering, and things that make very hight raycasting possible but they still need the CPU without the CPU we do not have an way for executing the programs and in case you don't know GPU IS SPECIFIC FUNCTIONS CPU IT CAN NEVER EXECUTE FUNCTIONS OF A CPU IF THAT happen why the hell we would need CPU's as GPU is more faster... And the modified version that i have does not contain libm.so.3 but libm.so.4 modified check it maybe you can see what it is...

THAT'S NOT THE POINT!!!
The phrase "GPU limited" basically means that you can get better performance with a better graphics card. Sure, with a better CPU, you can get a few more FPS, but a new GPU will give you a much larger performance boost. The CPU basically just tells the GPU "render these shapes in this environment", and it does it..

As Tari said, GPU Limited doesn't mean "only uses GPU" Basically if you upgrade your CPU to one thats 50% faster, you won't get a 50% gain, more like a 5% FPS gain (unlesss you have a really crappy CPU to begin with). However, if you switch from one GPU to another thats 50% faster, your game will be 50% faster - the GPU is the bottleneck, not the CPU

Oh, and new GPUs are fully programmable, meaning they can do quite literally anything a CPU can For example, soon they will also take care of physics processing, and there have been programs made that run solely on the GPU, but aren't graphical. However, it is a mistake to say that GPUs are faster than a CPU, as this isn't technically correct. Remember that GPUs are massively-parallel. My 7900GT has 24 pixel pipelines, which would be roughly equivelant to a 24-core CPU. As graphics is an inherintly parrallel task, this is a very efficient design. However, it can be rather hard to code a program to effectively and fully utilize 2 cores in a CPU, much less 24.

And thanks for bringing up the GNU issue! Further proof that FreeBSD won't make any noticeable difference over linux, and that is.... *drum roll* EVERYTHING ELSE IS THE SAME!!! They use the same compiler, libraries, shell, etc... The *only* difference is the kernel, which is NOT the most important part, nor does it even have the largest impact in speed. You seriuosly need to go do some research.

As for your ASM in FreeBSD is faster than ASM in Linux - are you retarded? I am serious now... If you contributed to FreeBSD and/or linux, then god help us all...

And you most definitely can't read, as I never said "make" only links to libraries. I'm not sure where you get this crap, but you aren't helping FreeBSD's image any by posting this BS

Oh, and I know about source-distrabutions, as I've built my entire system from source, whereas FreeBSD is a largely a binary distro

not only the kernel when you create a program specific for freebsd you could do this
mov eax,???
mov ebx,???
mov ecx,???
int 80h or call xxxxx
and
linux version
mov eax,???
mov ebx,???
mov ecx,???
push eax
push ebx
push ecx
into 80h or call xxxx

so who is the faster tell me because i steal believe that's freebsd althouth freebsd gives you the choice of the C....

but freebsd is faster in getting in and out of libraries

about GPU they aren't and they will not be, as GPU's they are like DSP's and if you think that well i must say noobishness is with you and about my programming well let me remind one thing linux uses my code in order to run multithread why they do that well maybe because is the most fastest... well friends of myne from 'caixa magica' have lauthed when you said that and they are from linux i know many people in linux world and some of them program for freebsd why hmm i don't know, and about phisics for god there will not be included in GPU but in the new phisics asus card... One thing you are right CPU does really tell's the GPU what it must executes and if you want really to know i friend of mine have tried to put the GPU to run code in robotic 2004 and look he was unsucessfull because he have tell that GPU have to change a lot in order to execute code.... well
next time i will that you say somethings like that i will not even answer... two times i have tested you about crypt and basic systems knowledge and the two times you have not even answer well althout they are noob question's you aren't smart enought in order to answer let me think why.... noob yah 100% sure

Any optimizing compiler could do the same thing - that's a function of how well a routine was written (not destroying registers) instead of the kernel itself.

no understood that that's the way how linux works the paramters have to be passed by the stack and freebsd supports the two ways is like this on windows well get olly and try to debug a program then search for message box or other function you will see that they use the C's standart way of passing parameters whitch is a litle slow 'not on todays machines' but as freebsd supports many architectures
well check this it will help you understanding what i'm saying
http://www.int80h.org/bsdasm/

No, I get that part, but I think a few tiny wrapper changes could easily do that for any shell.

when you use linux you must use the C statement of passing parameters and in FreeBSD is our choice... for example imagine that we try this on mirageos
LD IX,sprite
LD B,16
LD C,1
LD A,8
LD L,9
PUSH IX
PUSH HL
PUSH BC
PUSH AF
call putsprite

well if we do this an error will happen because the mirageos routines don't handle the stack statement unless we pop them after we call the function.
So in first place why we have pushed if then we need to pop well linux and microsoft works with somekind of this statement
only they pop the registers inside the routine, like
this


mov eax,0
mov ebx,03
mov edx,???
PUSH eax
PUSH EBX
PUSH EDX
call some_weird_function




now in the function it will make somehting like this

some_weird_function:
....

ret n ;where n is the number of pops we must do

No, I get that already. I do know x86 ASM, you know.

Ok, let me say this ONE last time... Modern (DirectX 9.0C+ compliant) GPUs are FULLY PROGRAMMABLE!!! They are NOTHING like a DSP (nor were they for the last ~10 years ) If you say its impossible, then you are an idiot, because IT HAS ALREADY BEEN DONE. There HAVE been NON-VISUAL programms that run COMPLETELY ON THE GPU ALONE.

As for function argument method, that is a very, VERY weak example, and has no indication on the speed of FreeBSD itself - it is merely a design choice.

And although you only pointed out where FreeBSD has the advantage, using the stack also has its own advantages for passing arguments.