 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] mac com> wrote:
: Well, the unlimited version will parse a little slower, since it will
: have to resize the array every so often, but unless you have some really
: huge blend maps it won't be noticeable, and it will only affect parse
: time. I took the approach of resizing the array when needed for
: simplicity.
Wouldn't a better and faster approach be to read all the entries into
a temporary list and then allocate an proper-sized array, copy the entries
in there and then free the list?
I think that a temporary list would take less memory than a temporary
dynamic array.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a840791@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Wouldn't a better and faster approach be to read all the entries into
> a temporary list and then allocate an proper-sized array, copy the
> entries in there and then free the list?
> I think that a temporary list would take less memory than a temporary
> dynamic array.
Maybe slightly faster at parse time, but would require one of these:
1: Changing the blend map data structure to a linked list. Pro: faster
parsing. Cons: slower rendering, slightly more memory, more coding.
2: Adding a pointer to each element of the blend map structure, so you
can use them in a linked list, but store them in an array for final
usage. Pros: faster parsing, and render speed not directly affected.
Cons: much more memory wastage, and even more coding.
3: Making a separate data type for elements of lists and of arrays, use
the list type for the temporary list and copy to an array of the array
type. Pros: Fast parsing speed, same rendering speed, and only
temporarily uses more memory. Cons: Much more coding than either of the
above, and seems like a generally clumsy solution.
If I use the resizeable array approach, it fits into the existing code
very well (in fact, it's almost like this was planned from the start,
but never implemented), doesn't take a lot of work to implement, and is
only noticeably slower every once in a while, when it has to resize the
array (for example, every 64 items). It wastes some memory temporarily,
but that can be removed, and it doesn't amount to much anyway. (I think
the color_map code does remove unused entries, but I'm not sure about
the other types.)
You could even include a little optional parameter to specify the number
of items, so the array would be allocated once. If someone really needs
to worry about blend map memory and parse speed, they could then specify
the number of entries in their map and the array would never have to be
resized.
I really don't think the speed advantage of using a temporary list would
be noticeable except in extreme cases of several hundred entries, when
the array has to be resized multiple times...and then you would probably
have to do a benchmark to notice it.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] maccom> wrote:
: 1: Changing the blend map data structure to a linked list. Pro: faster
: parsing. Cons: slower rendering, slightly more memory, more coding.
I was talking about a TEMPORARY list. First you read the data into the
temporary list, then you allocate a proper-sized array, copy the data from
the list into the array and then destroy the list.
: 3: Making a separate data type for elements of lists and of arrays, use
: the list type for the temporary list and copy to an array of the array
: type. Pros: Fast parsing speed, same rendering speed, and only
: temporarily uses more memory. Cons: Much more coding than either of the
: above, and seems like a generally clumsy solution.
Coding a list is very easy and fast to code. And with the upcoming pov3.5
you'll be able to use STL lists so you don't have to code at all.
And it's not a clumsy solution. It's a clean and smart solution. Using
a (hand-coded) dynamic array is the clumsy solution.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a87d2dd@news.povray.org> , Warp <war### [at] tagpovrayorg>
wrote:
> Coding a list is very easy and fast to code. And with the upcoming pov3.5
> you'll be able to use STL lists so you don't have to code at all.
You won't. Only the iostreams should be used (with a lot of care).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3a87e7c7$1@news.povray.org...
> In article <3a87d2dd@news.povray.org> , Warp <war### [at] tagpovrayorg>
> wrote:
>
> > Coding a list is very easy and fast to code. And with the upcoming
pov3.5
> > you'll be able to use STL lists so you don't have to code at all.
>
> You won't. Only the iostreams should be used (with a lot of care).
>
Why not ? The point of the STL is that it is generic, i.e. designed to
work with _any_ data classes - you really have to work hard to make your
classes incompatible with the STL, so, what's up with the C++ code in 3.5
that makes it so ?
--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3a87d2dd@news.povray.org...
> Chris Huff <chr### [at] maccom> wrote:
>
<sniped stuff about dynamically allocated arrays and linked lists>
>
> And it's not a clumsy solution. It's a clean and smart solution. Using
> a (hand-coded) dynamic array is the clumsy solution.
>
JPDA[1] - How is hand-coding a list any more clumsy and any less clean
and smart that hand coding a dynamic array, exactly ?
All a linked list is is a fancy dynamic array (in fact there's probably
more work (and, therefore, more chance of screwing something up) in hand
writing a linked list - the dynamic array just needs to keep track of the
current used and max sizes, a linked list requires maintaining previous
and/or next node pointers).
The only benefit you get with a linked list is improved random access
speeds.
--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk
[1] JPDA - Just Playing Devils Advocate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a8945a1@news.povray.org> , "Scott Hill"
<sco### [at] ncgraphicsnet> wrote:
> Why not ? The point of the STL is that it is generic, i.e. designed to
> work with _any_ data classes - you really have to work hard to make your
> classes incompatible with the STL, so, what's up with the C++ code in 3.5
> that makes it so ?
You missed the point. It is not that we are not compatible with the STL
(I never said that, did I?), but that there is no compatible STL. Most
platforms are far behind when it comes to an ISO C++ STL implementation.
It starts with different, non-standard include file names, add continues
with missing or different names for classes and methods, not to mention
bugs. For example, using standard STL would make compiling with the
currently available gcc plus libraries impossible (we spend a few days
sorting out just iostreams). Other problems include template support in
many compilers, and so on, and so on. Besides, we would be using two
memory models, one based on malloc/free, another on new/delete. Not all
compilers can (or want) to map new/delete to malloc/free so you also
could get increase memory fragmentation. Overloading new/delete is a
nice idea, but again requires so may platform specific changes (because
nobody really supports this part of the standard in the same way). Some
compilers don't even support block-level variable scope!
So, in summary, no STL in 3.5. We just hope the situation improves in
the next 12 - 24 month (especially gcc 3.0), but initial 4.0 development
(if we can use the STL at all by then) might still be a pain...
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3a894f89$1@news.povray.org...
> In article <3a8945a1@news.povray.org> , "Scott Hill"
> <sco### [at] ncgraphicsnet> wrote:
>
> > Why not ? The point of the STL is that it is generic, i.e. designed
to
> > work with _any_ data classes - you really have to work hard to make your
> > classes incompatible with the STL, so, what's up with the C++ code in
3.5
> > that makes it so ?
>
> You missed the point. It is not that we are not compatible with the STL
> (I never said that, did I?)
No, you never, not in so many words anyway - your statement was a little
ambiguous so it could have been read that way.
> but that there is no compatible STL.
Tell me about it ! I was forgetting POV's cross-platform and therefore
cross-compiler too (note to self : just 'cos you code windows apps all day
and read windows programming books and eat windows code and sleep in a world
of windows, it don't mean windows is all there is....(Hmm, maybe I should
get out more....))
As you say, hopefully they'll fix a standard for the STL and then people
could actually work towards a target that isn't moving about all the time -
as it is currently you can't really blame compiler writers for the lack of
STL support when the ISO/ANSI boards keep changing there minds on just what
the standard is.
BTW, why did you say "Only the iostreams should be used" ? As I
understand it, they're the least supported part of the STL.
--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 13 Feb 2001 16:11:18 -0000, Scott Hill wrote:
> BTW, why did you say "Only the iostreams should be used" ? As I
>understand it, they're the least supported part of the STL.
Because they've been successfully encapsulated in a suitably cross-platform
way in the current source.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Tue, 13 Feb 2001 16:11:18 -0000, Scott Hill wrote:
> > BTW, why did you say "Only the iostreams should be used" ? As I
> >understand it, they're the least supported part of the STL.
>
> Because they've been successfully encapsulated in a suitably
cross-platform
> way in the current source.
>
Cool.
Actually....
<rant on> Having thought on this a little - stuff like this really
annoys me - standards committees are meant to reach an agreement about what
the standard means, not keep changing there minds, dev tools developers
should stop arsing about (though as I said - it's hardly their fault with
moving targets an' all that jazz) and only release complete libraries that,
at the minimum, comply to _some sort of standard_ and we programmers should
all stop just taking all this shit lying down - we bitch and moan privately
about the shit standards, buggy dev tools, moving targets and the like but
bugger all get's done - it's about time we used some of the power we have -
without any programmers doing any actual development on a platform, that
platform will die - we have the ultimate power to decide what makes it and
what doesn't - we should exercise it and stop putting up with this shit -
after all, it's us that get's the blame in the end - Project behind schedule
? That'll be the lazy developers. Bloaty code ? That'll be the lazy
developers. Bug-ridden shit ? That'll be the lazy programmers. Trouble is
sometimes you only get shit to work with and no matter how well you sculpt
it, shit is shit. <rant off>
--
Scott Hill.
NC Graphics (Cambridge) Ltd.
http://www.ncgraphics.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
