Thread: RE: XML was RE: [GD-General] RE: A portable preferences library b ut has nothing to do with them an
Brought to you by:
vexxed72
From: Gareth L. <GL...@cl...> - 2003-12-16 18:15:45
|
But I think the point has been missed. The issue here (the reason I entered this discussion) was that not only the data format was (imo) bad (text file not parsed) but a lot of proccessing goes on with the data. He mentioned kd-tree generation for example. Hell, why not just pre-generate the kd-tree and store that into the xml ? Surely that is a step in the right direction ? > -----Original Message----- > From: Alen Ladavac [mailto:ale...@cr...] > Sent: 16 December 2003 18:54 > To: gam...@li... > Subject: Re: XML was RE: [GD-General] RE: A portable > preferences library > > > Gareth and Jorrit are going each too far in their own > direction. I believe > that the reality lies in between. Putting everything into > platform-specific > down-to-the-bit-optimized binary data is killing a fly with a > cannon, for most > purposes. The only place where the load peformance matters so > much is if you > want to stream your data during gameplay, and if you need it > quickly, so you > have very little CPU to spend. Other than that, the only > thing that you should > care about is that you are limited by HDD throughput, not by > CPU speed. As > long as your CPU is ahead of the HDD, you are fine. > > What I do is to have a binary format that is universal and > that can load any > kind of objects. It can swap the bytes for endianness, etc. > but it knows in > advance what layout looks like (in endianness neutral > format), and doesn't > have to parse ASCII, let alone generic XML syntax. This is > not giving any > generality away, while still allowing you to keep you loading > speed under > control. I don't know of any platform where the CPU is so > slow that it cannot > perform endianness swapping and such small adjustments while > loading. But > going towards XML might be just a bit of an overkill. I say > _might_, not _is_. > ... because I asked the original question about loading speed > plainly because > I am interested in whether XML can be as efficient as a > binary format. I > belive that it is not very likely, but not impossiible, and I > will accept any > well profiled arguments. While this: > > >In case of CS making such a faster loader > >really is a HUGE amount of work. We have LOTS of different > data to save > > is not something like that. I understand that CS team is not > working on a > budget, and it is great that they do stuff for fun and for > others (though back > when I was doing coding for my own fun, I wanted the results > to be perfect as > well, but thats a different topic). But priorities of CS team > _have nothing to > do_ with XML qualities. If I recall, it was the performance > of XML parsers > that was discussed, not the idea of whether a loader should > be fast or not. If > I say that my loader should be fast, then I guess it should. > I was just hoping > that someone can show me some exact numbers. > > On a side note, this comment that "it is a HUGE ammount of > work", is based on > a wrong assumption. Their problem is that the design was > wrong. If they went > for generic binary format from the start, the work would be > near zero. But I > digress. > > Can you Jorrit please get some more correct profiling data. > It doesn't matter > that your app does preprocessing in-game, it is your choice. > But how fast is > the parser itself? > > Thanks, > Alen > > > > ----- Original Message ----- > From: "brian sharon" <pud...@po...> > To: <gam...@li...> > Sent: Tuesday, December 16, 2003 16:16 > Subject: Re: XML was RE: [GD-General] RE: A portable > preferences library > > > > Would you please give it a rest? In case you haven't > noticed there's > > no "shop" involved for you to return his game to, as he's giving his > > work away freely. Jorrit is not doing this as a full-time job. If > > load times are not his first priority I can hardly blame > him, it's not > > exactly the "fun" part of the job. > > > > Please visit http://crystal.sf.net to get clued in. > > > > --brian > > > > On Tuesday, December 16, 2003, at 07:59 AM, Gareth Lewin wrote: > > > > > Sorry, but you are just wrong. > > > > > >>> Lets not ignore the fact that loading bits of the level is > > >> way easier with a > > >>> binary specific format that can be dumped directly into data > > >> structures. > > >>> > > >>> > > >> Yes but that's not portable. CS has to run on all kinds > of operating > > >> systems and cpu's. We can't > > >> dump binary structures like that. The endianess wouldn't be > > >> correct and > > >> padding can differ > > >> too. > > >> > > > > > > There is no reason whatsoever for final proccessed data to be > > > portable. You > > > have your data in xml. You preprocess it into binary format for a > > > specific > > > build/platform. And you use that. Your load times go from > 16seconds to > > > 2 or > > > 3 seconds. > > > > > > And the amount of effort required to implement binary > saving off of > > > structures isn't anywhere near comparable with the effort > required to > > > tweak > > > the speed of a graphics engine. Not to mention that 16-20 > second load > > > times > > > would have me returning the game to the shop. > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: IBM Linux Tutorials. > > > Become an expert in LINUX or just sharpen your skills. > Sign up for > > > IBM's > > > Free Linux Tutorials. Learn everything from the bash shell to sys > > > admin. > > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > _______________________________________________ > > > Gamedevlists-general mailing list > > > Gam...@li... > > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > > Archives: > > > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: IBM Linux Tutorials. > > Become an expert in LINUX or just sharpen your skills. > Sign up for IBM's > > Free Linux Tutorials. Learn everything from the bash shell > to sys admin. > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > _______________________________________________ > > Gamedevlists-general mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign > up for IBM's > Free Linux Tutorials. Learn everything from the bash shell > to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
From: Gareth L. <GL...@cl...> - 2003-12-16 18:41:43
|
We are going in circles here, his data is zlib compressed, so the harddisk costs are equivalent to a binary file (based on what Jorrit said). And for the record, there are always many right ways. But there are also wrong ways. Oh, and please Jorrit, I never meant to offend. I feel (based on offline emails) that I might have offended. I'm sorry if that happened, as I think I have posed only technical issues and nothing personal. > -----Original Message----- > From: Pierre Terdiman [mailto:pie...@no...] > Sent: 16 December 2003 18:32 > To: gam...@li... > Subject: Re: XML was RE: [GD-General] RE: A portable > preferences library > but has nothing to do with them anymore > > > > Hell, why not just pre-generate the kd-tree and store that > into the xml ? > > Because the CPU is way faster than the HD, as already stated. > So, I wouldn't > be surprised if generating the kd-tree was actually faster > than loading a > huge text file (say XML). I certainly compute my AABB-trees > on-the-fly, for > example. > > (Now I'm not saying that's the Right Way because, as you all > should know, > there's no such thing as a Right Way in those recurrent > A-vs-B threads. When > there's an actual Right Way, everybody agrees and people > don't waste their > time discussing it). > > Pierre > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign > up for IBM's > Free Linux Tutorials. Learn everything from the bash shell > to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
From: Jorrit T. <Jor...@uz...> - 2003-12-17 07:26:20
|
Gareth Lewin wrote: >Oh, and please Jorrit, I never meant to offend. I feel (based on offline >emails) that I might have offended. I'm sorry if that happened, as I think I >have posed only technical issues and nothing personal. > > I'm not easily offended :-) Greetings, |
From: Pierre T. <pie...@no...> - 2003-12-16 18:26:39
|
> Hell, why not just pre-generate the kd-tree and store that into the xml ? Because the CPU is way faster than the HD, as already stated. So, I wouldn't be surprised if generating the kd-tree was actually faster than loading a huge text file (say XML). I certainly compute my AABB-trees on-the-fly, for example. (Now I'm not saying that's the Right Way because, as you all should know, there's no such thing as a Right Way in those recurrent A-vs-B threads. When there's an actual Right Way, everybody agrees and people don't waste their time discussing it). Pierre |
From: J C L. <cl...@ka...> - 2003-12-16 18:44:29
|
On Tue, 16 Dec 2003 19:31:46 +0100 Pierre Terdiman <pie...@no...> wrote: > (Now I'm not saying that's the Right Way because, as you all should > know, there's no such thing as a Right Way in those recurrent A-vs-B > threads. When there's an actual Right Way, everybody agrees and people > don't waste their time discussing it). <breaks down and cries tears of relief> While not game-related data (gene expression data as happens) I've found that I can load, parse, and cross link a 40Meg XML file with a moderately heavy rate of cross and external links (few score per K) in about 11 seconds on my far from cutting-edge desktop. Raw IO time to simply suck the same data off disk is around 5 seconds. That makes for a second and a half per 10Meg of XML data for parsing and linking, and this is without any attempt to optimise. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
From: Alen L. <ale...@cr...> - 2003-12-16 21:17:13
|
Can you please explain this calculation in more detail? You get 10MB /1.5s = 6.7M/s ? But you said you load 40MB in 11s, what I would say is 3.6 MB/s. Please note that you should not substract IO time from the total loading time, as CPU should be working in parallel with the DMA, otherwise you are doing something _very_ wrong. Anyway, either 7MB/s, or 3.6 MB/s, this is just awfully slow. A 40xCDROM has transfer rate of 6MB/s. You say you are parsing data at that rate? Those are certainly not some impressive numbers. :( Alen J C Lawrence writes: > On Tue, 16 Dec 2003 19:31:46 +0100 > Pierre Terdiman <pie...@no...> wrote: > >> (Now I'm not saying that's the Right Way because, as you all should >> know, there's no such thing as a Right Way in those recurrent A-vs-B >> threads. When there's an actual Right Way, everybody agrees and people >> don't waste their time discussing it). > > <breaks down and cries tears of relief> > > While not game-related data (gene expression data as happens) I've found > that I can load, parse, and cross link a 40Meg XML file with a > moderately heavy rate of cross and external links (few score per K) in > about 11 seconds on my far from cutting-edge desktop. Raw IO time to > simply suck the same data off disk is around 5 seconds. That makes for > a second and a half per 10Meg of XML data for parsing and linking, and > this is without any attempt to optimise. > > -- > J C Lawrence > ---------(*) Satan, oscillate my metallic sonatas. > cl...@ka... He lived as a devil, eh? > http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 |
From: J C L. <cl...@ka...> - 2003-12-16 21:39:12
|
On Tue, 16 Dec 2003 22:17:07 +0100 Alen Ladavac <ale...@cr...> wrote: > Can you please explain this calculation in more detail? You get 10MB > /1.5s = 6.7M/s ? But you said you load 40MB in 11s, what I would say > is 3.6 MB/s. Please note that you should not substract IO time from > the total loading time, as CPU should be working in parallel with the > DMA, otherwise you are doing something _very_ wrong. The code in question does: sz = get_size_of_file () read (h, buf, sz) parse (buf) As such load and parse are entirely separate. And yeah, by arithmetic was off. I'm parsing and cross linking (there's a fair few URI links in the data) in roughly 6 seconds. > Anyway, either 7MB/s, or 3.6 MB/s, this is just awfully slow. This is an old slow machine, a PII-333 -- I said it was far from cutting-edge. As it is a multi-user host there's also a fair bit going on otherwise (mostly network IO rather than CPU or disk), but I didn't check for to see what extent the other loads may have had. I wasn't trying for anything rigorous, merely a key to incite people to test with their actual loadings, not a quick hack with a set of gene AFFY data. > A 40xCDROM... I was reading from disk possibly NFS over 100bT (can't check right now, don't have access to that machine from where I am now). That machine doesn't have a CD. > ... has transfer rate of 6MB/s. You say you are parsing data at that > rate? Those are certainly not some impressive numbers. :( Certainly they're not impressive. They weren't intended to be. I suggest you check them on a more representative host with code that wasn't written as quickly as possible and for data that more closely matches your loads. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
From: Alen L. <ale...@cr...> - 2003-12-17 07:47:47
|
> The code in question does: > > sz = get_size_of_file () > read (h, buf, sz) > parse (buf) > > As such load and parse are entirely separate. I see. > This is an old slow machine, a PII-333 -- I said it was far from > cutting-edge. Frankly, I'd like to have that to be more like at least 10-20MB/s on a Celeron 733. Not to mention some even slower CPUs, that most of us would like it to run on. ;) > > A 40xCDROM... > > I was reading from disk possibly NFS over 100bT (can't check right now, > don't have access to that machine from where I am now). That machine > doesn't have a CD. I mentioned the 40xCD as a yardstick to compare the speed against. It is deemed as something very slow, and your CPU activity while loading should always have much better throughput than that. Alen > > ... has transfer rate of 6MB/s. You say you are parsing data at that > > rate? Those are certainly not some impressive numbers. :( > > Certainly they're not impressive. They weren't intended to be. I > suggest you check them on a more representative host with code that > wasn't written as quickly as possible and for data that more closely > matches your loads. > > -- > J C Lawrence > ---------(*) Satan, oscillate my metallic sonatas. > cl...@ka... He lived as a devil, eh? > http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
From: Jorrit T. <Jor...@uz...> - 2003-12-17 07:25:08
|
Gareth Lewin wrote: >But I think the point has been missed. The issue here (the reason I entered >this discussion) was that not only the data format was (imo) bad (text file >not parsed) but a lot of proccessing goes on with the data. He mentioned >kd-tree generation for example. > >Hell, why not just pre-generate the kd-tree and store that into the xml ? >Surely that is a step in the right direction ? > > As I explained in another mail I cannot do that because the kd-tree is not fixed. Depending on hardware configuration a different kd-tree setup may be selected. But it doesn't matter. kdtree calculation is VERY fast. Greetings, |