Archvile
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Porting source ports to Android 4.0
Pages (2): « 1 [2]  
Author
All times are GMT. The time now is 00:47. Post New Thread    Post A Reply
Blzut3
Member


Posts: 496
Registered: 06-04



Maes said:

It's not unusual to be able to make a more lightweight version of e.g. a Stack or ArrayList class than the built-in one, even for a novice programmer, especially if limited to a single data type. What such re-implementations often "lose" are some frills like thread safety, generics (but not always), implementation of some exotic interfaces, serialization, etc. and of course having to prove from the ground up that they are correct.


While this may be true, one thing most other languages don't have to put up with is binary bloat from using their standard templates. In Java generics are basically a way of having the compiler handle Object casts for you and don't really exist at run time. I'm not familiar with all the implementation details of ArrayList, but I can't imagine where it would perform significantly poorly from another implementation. I can see making specialized containers for primitives, but that's about it.

C++ templates generate code at compile time, which has many benefits, but it does mean that heavy template usage (as seen in the STL) can bring the binary size up dramatically. I'm sure having all that code duplication (and I reiterate that it usually isn't a small file size difference) doesn't help with CPU caching, but I'm not an expert here.

Old Post 08-25-12 11:16 #
Blzut3 is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7698
Registered: 01-03



Blzut3 said:

C++ templates generate code at compile time, which has many benefits, but it does mean that heavy template usage (as seen in the STL) can bring the binary size up dramatically. I'm sure having all that code duplication (and I reiterate that it usually isn't a small file size difference) doesn't help with CPU caching, but I'm not an expert here.




The binary bloat itself is probably not the worst thing here. If there's dead code it just won't be used.


But with STL it's more like it even creates larger code for the same operations that are performed by significantly less code in more lightweight packages - and in the end nobody will be able to convince me that a bloated class performs better than a more streamlined one.

The thing with STL is that the code is so intermingled and obfuscated that it's close to impossible to see how it all works together and what pieces of code are actually executed to perform a certain operation. I really don't like working with such code. It may do horrible things you aren't even aware of (like the copy-by-value stuff Quasar mentioned earlier.)

Old Post 08-25-12 12:06 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8780
Registered: 06-06



Blzut3 said:

When I converted ECWolf from std::vector, etc to ZDoom's containers. The size of the binary went from several MB to less than a MB IIRC. The std containers are quite bloated.

So I was better off when I didn't know about STL, and kept reinventing things like "List" data structures? Damnit, and thanks for the tip :-/

Does STL usage have a large RAM footprint? Maybe that's more important to consider (on hard-disk personal computers)...

__________________
Automatic Wolfenstein - Version 1.0 - also on Android

Old Post 08-25-12 14:16 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2075
Registered: 08-03


The vast majority of the time, you don't need to roll your own data structures at all. Unless you are working on truly "hot path" code like that in the guts of say a software renderer, there is little point in shunning the standard library.

Old Post 08-25-12 19:21 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7698
Registered: 01-03


It depends on what you want to do with it.
Sometimes you just can't afford to let implementation differences to get in the way, so in Doom terms STL may be unsuitable when it comes to demo sync issues. You just can't risk to have different algorithms to produce results that aren't guaranteed to be 100% identical in all cases.

Anyway, regarding std::vector and ZDoom's TArray, since I have both I tend to use the one that's more to my liking and that's clearly the ZDoom version.

Old Post 08-25-12 20:02 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 2075
Registered: 08-03


Naturally it does depend on how you use them, however, I would say that if your not using the STL for some task is because of the potential for implementation details changing the outcome then you haven't dutifully considered the solution in the first place; i.e., you've failed to encapsulate and then define it unambiguously. Edit: But then one could say that by implementing your own structures that ensure whatever rule(s) your solution demands then you have done just that. Personally though, I only consider rolling my own data structures when absolutely necessary.

Last edited by DaniJ on 08-25-12 at 20:25

Old Post 08-25-12 20:12 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
odysseyofnoises
Member


Posts: 436
Registered: 09-10


So how long before I can start using ZDoom on my Android phone? :P

__________________
Your rifle is only a tool. Your brain is your primary weapon. Use it first, then your rifle.

Old Post 11-13-12 01:29 #
odysseyofnoises is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12264
Registered: 07-06


The fastest path today would probably be firing a PC emulator on it, hoping that you get enough emulated power to match a Pentium I @ 200 MHz running Windows 98 (lowest specs I ever ran ZDoom "playably" with vanilla maps), starting ZDoom (software mode only!) at a low resolution (640 x 400 as an absolute tops) and hope for the best ;-)

This might be barely feasible on a GHz class CPU. Don't expect the batteries to last too long, though, and I have no idea how the controls would map.

Old Post 11-13-12 02:06 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
odysseyofnoises
Member


Posts: 436
Registered: 09-10


I have a samsung galaxy s2, so power is not a problem. I also tried to run ZDoom using adosbox but that gave me an error. I mostly want to install it so that I can play multiplayer (that is one of the reasons I wouldnt want to run it through a windows installation) and zdoom supports more maps. GZdoom would be even better... I think that runnng ZDoom on the android operating stem is a very worthy persuit in the name of DOOM science, heh. But not an easy one :/

__________________
Your rifle is only a tool. Your brain is your primary weapon. Use it first, then your rifle.

Old Post 11-13-12 07:34 #
odysseyofnoises is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 00:47. Post New Thread    Post A Reply
Pages (2): « 1 [2]  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Porting source ports to Android 4.0

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.