Language:
switch to room list switch to menu My folders
Go to page: First ... 99 100 101 102 [103] 104 105 106 107 ... Last
[#] Tue May 31 2011 10:57:54 EDT from IGnatius T Foobar @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

The original question asked was something to the effect of, if you have one function which produces data and another which consumes it, which one should be the caller and which should be the callee?

It would seem that such a program would be better served by putting *neither* function in charge, and instead have the main loop call each of them in turn, passing buffers of data back and forth as appropriate.

Why is this approach not discussed? (And no, I wasn't really serious about going multithreaded, though it poses some interesting things to think about.)

[#] Tue May 31 2011 11:45:26 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Er, actually, that is what he's doing (and the problem he is trying to solve).

He's just kind of involved with some of the semantics of it, at least in terms of making the program look more legible (which is also a concern).  Because code should be maintainable, and relatively easy to read.  I suppose, in the end, he's found this lovely gray area where 'easy to read' means two different things.  It could be easy-to-read as in 'follow all the C-code instructions to understand how it works' or easy-to-read as in 'follow the general logic to understand how it works without getting caught up in some of the ignorable details'.

In the first pair of code snippets, he shows the 'original' code.  It's nice and legible, but heavy and not portable.

So, he showed a conventional way to rewrite the two functions so that they do just what you suggested.  The problem is, the code isn't quite as legible as the original code... in fact, it's downright ugly.

That lead to the approach he favors, which involves using coroutines.  He steps you through the whys behind the resulting code, eventually getting to the relatively nice looking code that works for him.

Then, he points out what a dick your boss would be for not accepting this kind of code because he prefers the 'follow all the c-code instruction' perspective instead of the 'follow the basic logic' perspective, which is kinda cute.



[#] Tue May 31 2011 11:52:16 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

On a semi-related note, I found Tom Duff's comment on Duff's Device amusing:

http://www.lysator.liu.se/c/duffs-device.html



[#] Tue May 31 2011 13:03:16 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think I found one other thing slowing down the original implementation that I downloaded.

Originally, the author set the macro BUFFERSIZE to some large value, ostensibly because he's expecting you to run files through it, and I guess he figured they might be large files.

My equivalent setting is only 4096, so I changed BUFFERSIZE to 4096 and recompiled.  It seemed to speed things up for the original implementation, to the point where it runs faster than my implementation for decoding (although my implementation using strings instead of iostreams is still much faster).  This is more in line with my expectations.  My code is still faster at encoding, though, but not by much.



[#] Tue May 31 2011 16:49:18 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


not really in boost. looks like the way to go for C++ developers who need fine-grained parallelism is http://threadingbuildingblocks.org/

[#] Tue May 31 2011 17:22:10 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Hmm... that's intriguing.  I should give that a closer looksee.



[#] Wed Jun 01 2011 04:53:31 EDT from dothebart @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

*gngn* where was the original discussion at? (shouldn't it belong into programming in first place?)

fleeb, I get this:

gcc base_xx.cpp -o test1
In file included from /usr/include/c++/4.5/unordered_map:35:0,
from base_64.h:18,
from base_xx.cpp:5:
/usr/include/c++/4.5/bits/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
In file included from base_xx.cpp:5:0:
base_64.h:285:12: error: 'unordered_map' in namespace 'std' does not name a type
base_64.h:476:4: error: 'char_lookup_t' does not name a type
base_64.h: In member function 'int tvr::decode::base_64::decode_value(char)':
base_64.h:451:10: error: '_alphabet_map' was not declared in this scope
base_64.h:455:5: error: 'char_lookup_t' has not been declared
base_64.h:455:35: error: expected ';' before 'found'
base_64.h:456:10: error: 'found' was not declared in this scope
base_64.h:456:19: error: '_alphabet_map' was not declared in this scope
base_64.h: In member function 'void tvr::decode::base_64::build_map()':
base_64.h:470:6: error: '_alphabet_map' was not declared in this scope

 

and the other one... no main?

gcc cdecode.c -o test
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 11
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 12
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 11
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 12
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 13
/usr/bin/ld.bfd.real: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 20
/usr/lib/gcc/x86_64-linux-gnu/4.5.3/../../../../lib/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'



[#] Wed Jun 01 2011 07:34:10 EDT from fleeb @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Jun 01 2011 04:53:31 EDT from dothebart @ Uncensored Subject: Re:

*gngn* where was the original discussion at? (shouldn't it belong into programming in first place?)

I got very, very angry in programming a while ago, and zForgot it.  This was the next best place.

fleeb, I get this:

gcc base_xx.cpp -o test1
In file included from /usr/include/c++/4.5/unordered_map:35:0,
from base_64.h:18,
from base_xx.cpp:5:
/usr/include/c++/4.5/bits/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

Yeah, I pointed out earlier that you might have a problem with my use of 'unordered_map'.  It is the one thing that was potentially difficult here, but I needed to use unordered_map for the hash table (faster than a binary table).  I could maybe create another kind of lookup table that doesn't require this, though, but it would potentially waste space instead.  If you have boost, change #include to <boost/unordered_map.hpp> (or whatever it is) and it should be just fine.  If you have tr1, use that instead.  Otherwise, try using -std=c++0x as the compiler suggests.

and the other one... no main?

I thought I got that... there's supposed to be a main in base_xx.cpp.  The DevStudio IDE love to use a version of main that provides for TCHARs instead of chars.  Just change whatever the IDE created to a normal main and it should be fine (I'm not using any command line arguments anyway).

 



[#] Wed Jun 01 2011 12:41:06 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Maybe your code is small enough that it remains inside the data and
code buffers of the cpu, too?

I was thinking something like this. Perhaps more spinning variables end up in registers your way.

[#] Wed Jun 01 2011 13:06:27 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, the updated archive (with base32 and base16, not to mention some bugfixes) is on http://www.fleeb.com/base_xx if you're interested.  It corrects the weird TCHAR main thing, but I'm still using unordered_map (at least until I can find something else that's fast but more available).



[#] Wed Jun 01 2011 15:35:00 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

On a semi-related note, I found Tom Duff's comment on Duff's Device
amusing:

The only problem with duff's device is that it really isn't all that useful. It's very cute, but that's about it.

[#] Wed Jun 01 2011 15:38:52 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well... it is useful in a very, very specific way.  You can implement coroutines in C/C++ with them.  So the problems solved best by co-routines are best solved with Duff's Device.



[#] Wed Jun 01 2011 16:17:32 EDT from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

In a way, the case's in a switch statement are essentially go-to labels, so any situation that might require the flexibility of a label could probably be made somewhat more organized by using a switch statement instead.

[#] Wed Jun 01 2011 18:56:14 EDT from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think Duff actually mentions that some optimizing compilers may be able to recognize what a rolled-up loop structure is doing and pick the fastest assembly code. In which case, using his technique may not get you any performance gains.

[#] Wed Jun 01 2011 18:19:27 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

and if you're going to use labels, you're sorta defeating the purpose of structured procedural programming.

The way I heard it the first time was that duffs device allows you to jump into the middle of a loop so you don't have to handle a start/end case pile of code before or after the loop.
That sounds great from a pretty programming point of view, but duffs device isn't terribly pretty to look at, and what really matters is what it compiles into, which I haven't actually seen, so maybe it's a better deal.
Seems to me an optimizer would detect a copy of some code handling the after-loop case and end up with the same result as if you had written duffs device.

[#] Wed Jun 01 2011 20:03:32 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Jun 01 2011 16:17:32 EDT from Spell Binder @ Uncensored
In a way, the case's in a switch statement are essentially go-to labels, so any situation that might require the flexibility of a label could probably be made somewhat more organized by using a switch statement instead.

For me, though, the more bizarre part is the way it continues within the loop... it's like jumping to the middle of the loop without even looking at the 'while' or 'for' statement, yet still working within the loop.  While I know better, my mind kind of feels like the evaluation is 'set up' at the beginning, and must be viewed before working within the loop's block.



[#] Wed Jun 01 2011 22:58:21 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think Duff actually mentions that some optimizing compilers may be

able to recognize what a rolled-up loop structure is doing and pick the


gcc -O3 -funroll-loops/-funroll-all-loops

[#] Wed Jun 01 2011 22:57:47 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Which is why, IIRC, the loop in duff's device is usually a do {} while ();

[#] Mon Jun 06 2011 17:42:33 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I think Duff actually mentions that some optimizing compilers may be

able to recognize what a rolled-up loop structure is doing and pick the

fastest assembly code. In which case, using his technique may not get

you any performance gains.

Also keep in mind duff wrote that in 1988 or something, and optimizing compilers have come a long way in 23 years.

[#] Mon Jun 06 2011 17:46:57 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Optimize-Options.html

So I started reading that.
my god. I'm old.

Go to page: First ... 99 100 101 102 [103] 104 105 106 107 ... Last