Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Aleksej Saushev <asau@xxxxxxxx>
- Date: Thu, 15 Oct 2009 23:02:58 +0400
Bernd Paysan <bernd.paysan@xxxxxx> writes:
Aleksej Saushev wrote:
I thought ahead and pointed you that "view into the matrix" doesn't
simplify anything, when done in Forth.
Yes, that's what you say, but there's no beef in your argument.
What you propose as Forth thinking, is worse. It assumes that you roll
custom solution each time you need it, even when there's not a single
reason for it to be custom.
You get that wrong. The Forth thinking is: Don't try to write an over-
generalized solution when all you need is a custom one. If you actually
need a general solution, write it up in a factored way so that you don't
have to resort to the over-general Swiss Army knife. GEMM is such an
example of an all singing and dancing Swiss Army knife.
This raises maintainance cost for humans: you have to remember more
concepts and more technical conventions. With GEMM (BLAS actually),
you are to remember: convention on types, which affects Forth as well,
since Forth uses same way to distinguish operations ("SF@" v. "DF@"),
convention on matrix types (genereal, symmetric, triangular, banded...),
some more selectors (transposed, left/right side...). You want to add
another level for vector views, so that instead of (in C notation):
val = ddot(height, &st[0][i], width, vec, 1);
I write, basically
view_st_subvec = vecviewalloc(&st[0][i], height, width);
view_vec = vecviewalloc(vec, height, 1);
val = BP_ddot(view_st_subvec, view_vec);
vecviewfree(view_vec);
vecviewfree(view_st_subvec);
And all this should be translated into Forth!
Instead of one line with clear pattern of scalar multiplication I have
_five_ lines, four of them doing stupid things of effective no-op.
If I do it not the way you suppose, show me your way and demonstrate how
it is meant to simplify my life.
How do you pre-allocate the pool? Do you propose fixed number of objects?
I propose to pre-allocate a fixed number of objects and *add* another fixed
number of objects when the pool has been exhausted. This bases on the
assumption that the pool usually is small, and the number of allocations and
deallocations is larger than the maximum pool size. It also bases on the
assumption that the allocation of N fixed sized objects is far cheaper than
N times the allocation of one fixed sized object through dynamic memory.
Thus you rely on general memory allocator, which isn't written in Forth way
as you describe it.
It is quite easy to implement your separate view objects in the oldest
Fortran available. Nobody does that not because it is impossible or too
complex, nobody does that because it is just useless and doesn't bring
any benefit, performance penalty rather. Sure, 13 exceeds Miller's
number, but not too much, and most BLAS operations fit common attention
span limits. Thus BLAS shows that Forth way of thinking is too
restrictive rather, here it forces maintaining separate view objects
even when performance penalty is obvious.
The performance penalty of GEMM is also obvious: it's over-generalized.
Every over-generalized solution pays a performance penalty, one or the
other. I'm not advocating over-generalized solutions. I just say that when
you need them, the BLAS way is not the Forth way. It's the Fortran way.
Application specific sub-languages are not specific to Forth.
No, but they are not typical in Fortran.
How about juggling 7 parameters? 5 parameters? "Don't do it" either?
The less, the better. Remember the "draw a rectangle" example? Juggle with
4 parameters or avoid it? The suggestion is: Better avoid it.
You can't keep talk in your memory, it _started_ from this rectangle example.
All we're talking about, is that Forth does it all wrong and all points, you
make, are either questionable or just invalid. I chose another example
specifically to break memory chain and make you think outside your well
established bounds. You've spectacularly failed to deal with it, when
you felt that I relaxed complexity constraints to dealing with 5 parameters
instead of 13, you returned to the same invalid rectangular example.
This example about drawing a rectangle in a Forth way is invalid for
following reasons:
1. Introducing global state doesn't simplify anything. It is complexification.
First it leads to reentrancy problems and thus you have to implement separate
stack to save and restore that state. Second, it imposes burden on programmer,
because since establishing "current" state, it is the responsibility of
programmer to remember it and to follow it.
2. Introducing single object is a bit better but not too much. It does
"simplify" problem in the sense of establishing clear borders and interfaces.
But in Forth this requires memory management and only replaces stack juggling
with either carefully writing selectors or name space management, which are
still the responsibility of programmer, since Forth lacks appropriate tools.
The latter part of problem with this object approach is that it requires
artificial "parameter" objects, if you specifically require all functions
to have at most 3 parameters. But this means that all these objects has to
have constructors, destructors and selectors. This suggests that you have
to deploy (or implement?) an object system in Forth, if you do have many
object types, so that you could benefit from this object system.
This brings us to the following considerations:
1) there're so many object systems in Forth and no one widely used;
2) basically there's no experience with object systems except some
demonstrational examples, there were debates around whether Neon model
is good or is not, nothing decisive and nothing further than that;
3) interoperability of different object systems, most of which are toys,
is questionable.
At last object approach isn't general enough and you may still have
5-parameter operations. Nothing guarantees that you will never have them.
Given all the above, using 4 parameters is the only sane way to draw a rectangle,
and you have to deal with it, if you care anything of reentrancy, scalability
and other complexity issues. Your suggestion in "better don't" style
reduces thus to "better avoid Forth." You are to find more clever way to
manage complexity, if you mean otherwise.
This kind of argument is repeated by all those extremal programming
advocates. The usual outcome of this approach is "640K is enough" and
other fixed limits like in your memory allocator above.
The problem of your argument is that my memory allocator does not have your
imagined limit.
Your memory allocator as you describe it, depends heavily on underlying
generic memory allocator, which is written as generic as possible.
That is, in extremely unforthy way.
In plain words, you state that Forth doesn't scale, which is nice,
because it proves my point, and that one doesn't need to think about
scalability problems, which is bullshit. It is obvious to any IT pro in
the modern world, but it doesn't seem so when you consider Forth
community.
Scalability goes up *and* down. The overgeneralized solution does not scale
down, it has a fixed overhead per invocation. If I implement a 3D graphics
library, I need some specialized matrix multiplications to transform the
view matrix (a 4 by 4 matrix, of which only a 3 by 4 subset is actively
used), BLAS is large overkill. Therefore, e.g. my 3D turtle graphics uses
special-cased operators for this single view matrix, and I know it won't
ever scale. It doesn't need to. The problem space of 3D graphics is never
going to require more than three dimensions. But I'm not paying the price
for having a generalized matrix library.
So, you insist on your invalid points. Alright, let's see.
1. Code. Fortran uses the same high-optimized routine,
Forth uses a bunch of special-cased routines.
1.1. Scalability upwards. Forth imposes more burden on programmer,
otherwise no difference.
1.2. Scalability downwards. Forth imposes more burden on programmer.
Forth loses.
2. Memory. Fortran passes parameters on stack and can use pre-allocated memory,
no heap required, Forth passes parameters on stack and on heap.
2.1. Scalability upwards. No difference.
2.2. Scalability downwards. Forth loses.
3. Performance. Fortran passes parameters right as it is (allocate + copy),
Forth allocates objects with custom allocator (more complex allocate + copy).
Forth loses.
If your point is that we don't do it like all the other people do it, well,
yes, that's the case. There is a reason behind it. It is against common
practice, and a lot of people don't like it, you included. It is not about
scalability problems, because if I make something that's supposed to scale,
I don't build in arbitrary limits. If I'm going to make something that's
supposed to be small and cheap, it has to have limits. Not arbitrary, but
natural limits.
The way you describe it has nothing in common with natural limits.
You describe it this way: if you need anything, simplify, and your
"simplify" assumes that one should implement non-generic solution
like using fixed-size fields for textual data.
--
HE CE3OH...
.
- References:
- Critique on my solution for an exercise. (check if a date is valid)
- From: CuppoJava
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Marcel Hendrix
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Bernd Paysan
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: CuppoJava
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Anton Ertl
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Aleksej Saushev
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Bernd Paysan
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Aleksej Saushev
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Bernd Paysan
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Aleksej Saushev
- Re: Critique on my solution for an exercise. (check if a date is valid)
- From: Bernd Paysan
- Critique on my solution for an exercise. (check if a date is valid)
- Prev by Date: Re: ANS Forth's third stack
- Next by Date: Re: Critique on my solution for an exercise. (check if a date is valid)
- Previous by thread: Re: Critique on my solution for an exercise. (check if a date is valid)
- Next by thread: Re: Critique on my solution for an exercise. (check if a date is valid)
- Index(es):
Relevant Pages
|
