Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryengine Source Code

github.com

Post reply on HN
Print view View original

141–149 of 149 posts

Re: Cryengine Source Code

#141

Post by jfkebwjsbx »

gmueckl wrote: post #116
Remnant44 wrote: post #113

Earlier quoted context omitted.

If you enable /Ox, the codegen basically drops to what you would expect: the vector version drops down essentially identical code to the new/delete (modulo a memset to enforce the clear to zero condition) It is a good illustration of why debug stl builds are such hot garbage though...

It is a good illustration for why using the STL is not always a good idea: you can't blindly take the perf hit from that kind of overhead in a debuggable build of a game that you still want to run at reasonably interactive frame rates.

False, most standard libraries out there allow you to configure whether you want extra checks or not.

Re: Cryengine Source Code

#142

Post by teawrecks »

iforgotpassword wrote: post #124
naikrovek wrote: post #84

Earlier quoted context omitted.

It's funny watching people reply to you without knowing anything about your skill set and experience. Jasper_ is the real deal, people.

I still don't know who he is, but just from the arguments brought up you can tell this guy has experience in this stuff. Those blanket statements like "never use goto" and "always trust stl" generally make me wary. I started out with gwbasic once, writing horrible goto spaghetti code. When moving through Pascal and C I eventually learned the "never use goto" mantra and naively tried to follow it at all cost. After I…

IMO it should be clear from the top of a for loop how many iterations it will run. A goto randomly inside the loop is akin to a side effect in a function. Sure it might be the easiest solution you can think of, and might even generate optimal code, but it's less readable and forces future maintainers to exert more effort to understand the code.

Re: Cryengine Source Code

#143

Post by iforgotpassword »

teawrecks wrote: post #142
iforgotpassword wrote: post #124

Earlier quoted context omitted.

I still don't know who he is, but just from the arguments brought up you can tell this guy has experience in this stuff. Those blanket statements like "never use goto" and "always trust stl" generally make me wary. I started out with gwbasic once, writing horrible goto spaghetti code. When moving through Pascal and C I eventually learned the "never use goto" mantra and naively tried to follow it at all cost. After I…

IMO it should be clear from the top of a for loop how many iterations it will run. A goto randomly inside the loop is akin to a side effect in a function. Sure it might be the easiest solution you can think of, and might even generate optimal code, but it's less readable and forces future maintainers to exert more effort to understand the code.

> IMO it should be clear from the top of a for loop how many iterations it will run.

How would you implement something simple like a lookup in an array? From this argument even a break in a normal for-loop would be bad since I wouldn't know anymore how many iterations it will take. So if you have a nested loop and a "goto end_outer_loop" that's perfectly fine.

Re: Cryengine Source Code

#144

Post by naikrovek »

kryptiskt wrote: post #123
naikrovek wrote: post #87

Earlier quoted context omitted.

Function calls have an overhead, and if the function is only used once it makes no sense to break it out. It also makes no sense to have a rule on the maximum number of lines for a function. These rules are often created by people who don't write software that needs to have high performance.

A function that is called once will always be inlined. Trust the compiler.

All languages? No.

Compilers are plenty stupid, and have not earned blind trust.

Re: Cryengine Source Code

#145

Post by amyjess »

user5994461 wrote: post #139
Nextgrid wrote: post #135

Earlier quoted context omitted.

I remember experiencing that actually. Just random damage every few seconds. Is there any reason why the "don't trust the client" mindset is not used in games despite it being accepted in web development?

The game was released in 2007, Windows XP era. The very idea of security was being discovered.

I mean, "don't trust the client" was a thing in the late '90s when people were exploiting client-controlled things in Ultima Online so much Origin had to change the way some communication worked to stop it.

The most famous example I can think of was UOExtreme revealing hidden players, because if a player was hiding their presence was still sent to the clients of every other player in the area just with a "hidden" flag set. There were a bunch of other similar exploits associated with that particular third-party tool, but that's the only one I remember.

(so while writing this I did some googling and found the patch notes where they fixed it: https://uo.com/wiki/ultima-online-wiki/technical/previous-pu...)

Re: Cryengine Source Code

#146

Post by Const-me »

jfkebwjsbx wrote: post #140
Jasper_ wrote: post #112

Earlier quoted context omitted.

> True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. I disagree. Having to jump to another function definition which is inline is a bigger mental block than following a goto. The large amount of arguments you'd need to pass might also be a barrier, as is the mental overhead of checking to see if this function might be called from elsewh…

> Having to jump to another function definition which is inline is a bigger mental block than following a goto. Local lambdas are ideal for this. > Are you suggesting that the code should have done something like this? Yes, but you can manage the array inside too. > I mean, sure, it's a very minor cleanup. It changes like, two lines though The point is that TempArray can be reused everywhere. This is a typical class…

> Local lambdas are ideal for this.

The problem with lambdas, you can't mark their operator() with __forceinline or __attribute__((always_inline)) attributes. For this reason, when writing high-performance manually vectorized code, lambdas are borderline useless.

> MSVC is not what you should be using if you want performance.

Security and compatibility has higher priority. gcc and clang don't deliver their C runtime libraries with windows updates. Also, debugging and crash diagnostic is much easier with MSVC.

It's same on Linux BTW, only with gcc.

Re: Cryengine Source Code

#147

Post by jfkebwjsbx »

Const-me wrote: post #146
jfkebwjsbx wrote: post #140

Earlier quoted context omitted.

> Having to jump to another function definition which is inline is a bigger mental block than following a goto. Local lambdas are ideal for this. > Are you suggesting that the code should have done something like this? Yes, but you can manage the array inside too. > I mean, sure, it's a very minor cleanup. It changes like, two lines though The point is that TempArray can be reused everywhere. This is a typical class…

> Local lambdas are ideal for this. The problem with lambdas, you can't mark their operator() with __forceinline or __attribute__((always_inline)) attributes. For this reason, when writing high-performance manually vectorized code, lambdas are borderline useless. > MSVC is not what you should be using if you want performance. Security and compatibility has higher priority. gcc and clang don't deliver their C runtime…

> when writing high-performance manually vectorized code

The point was not about manually vectorized loops in particular. Why is that a problem if you are manually doing it, though?

> Security and compatibility has higher priority.

In commercial games, not really.

As for "compatibility", I am not sure what you mean.

> gcc and clang don't deliver their C runtime libraries with windows updates.

AFAIK you can use Windows libraries just fine. No need for using a different libc.

> Also, debugging and crash diagnostic is much easier with MSVC.

AFAIK, Clang can produce debugging info that you can use with VS.

I don't work on the environment, but it is what I have read here.

Re: Cryengine Source Code

#148

Post by gmueckl »

jfkebwjsbx wrote: post #141
gmueckl wrote: post #116

Earlier quoted context omitted.

It is a good illustration for why using the STL is not always a good idea: you can't blindly take the perf hit from that kind of overhead in a debuggable build of a game that you still want to run at reasonably interactive frame rates.

False, most standard libraries out there allow you to configure whether you want extra checks or not.

But at least in the case of MSVC that comfiguration option leads to binary incompatibilities that make it an all or nothing option for everything that gets linked together statically. And the checks are so heavy that the "all" option becomes unbearably slow quite quickly. If your project hits a reasonable size, you end up requiring some clever solutions.

Re: Cryengine Source Code

#149

Post by Const-me »

jfkebwjsbx wrote: post #147
Const-me wrote: post #146

Earlier quoted context omitted.

> Local lambdas are ideal for this. The problem with lambdas, you can't mark their operator() with __forceinline or __attribute__((always_inline)) attributes. For this reason, when writing high-performance manually vectorized code, lambdas are borderline useless. > MSVC is not what you should be using if you want performance. Security and compatibility has higher priority. gcc and clang don't deliver their C runtime…

> when writing high-performance manually vectorized code The point was not about manually vectorized loops in particular. Why is that a problem if you are manually doing it, though? > Security and compatibility has higher priority. In commercial games, not really. As for "compatibility", I am not sure what you mean. > gcc and clang don't deliver their C runtime libraries with windows updates. AFAIK you can use Window…

> Why is that a problem if you are manually doing it, though?

Here’s couple examples: https://github.com/Const-me/DtsDecoder/blob/master/Utils/App... https://github.com/Const-me/SimdIntroArticle/blob/master/Flo... I would like to use lambdas instead of classes, but can’t, due to that defect of C++.

> In commercial games, not really.

In commercial games too. While they don’t care about security, they do care about compatibility and crash report diagnostics.

> As for "compatibility", I am not sure what you mean.

A windows update shouldn’t break stuff. A software or a game should run on a Windows released at least 10 years in the future.

> Clang can produce debugging info that you can use with VS.

According to marketing announcements. This page however https://clang.llvm.org/docs/MSVCCompatibility.html only says “mostly complete” and also “Work to teach lld about CodeView and PDBs is ongoing”. PDB support is not about VC compatibility, it’s about Windows compatibility really: the debugger engine is a component of OS, even of the OS kernel. WinDbg is merely a GUI client for that engine, visual studio is another one.

Overall, in my experience, the platform-default compilers cause the least amount of issues. On Windows this means msvc, on Linux gcc, on OSX clang. Technically gcc and clang are very portable. Practically, when you’re using a non-default toolset, you’re a minority of users of that toolset, e.g. the bugs you’ll find will be de-prioritized.

Post reply on HN