@@ -2,57 +2,34 @@ The first project I focused on when I became fun-employed was improving Vty: A t
22library for Haskell software.
33<lj-cut/>
44Oh I know what you're thinking... Well no, but *I* think it's rediculous to spend time on a
5−*terminal* library. Something like OpenGL or web related, hell anything where any significant activity
6−has happened in the past few years seems more reasonable. Oh well.
5+*terminal* library. Something like OpenGL or web related, hell anything where any significant
6+activity has happened in the past few years seems more reasonable. Eh! It was an entertaining
7+challange.
78
8−This is a diary of completing vty 4 mostly written after I was done. No really specific technical
9−stuff is contained in this post. I suppose it counts as a sort of postmortem.
9+This is a post-mortem, of sorts, for VTY 4. The primary goal was to document the overall development
10+process. A side goal is to provide an overview of the implementation aspects of VTY 4. It all
11+probably be separated into a few reasonably short posts instead of just one overlong post. Ah well!
1012
11−I had taken over as maintainer of vty 3 from Stefan O'Rear. Vty 3 already worked great and I didn't
13+I had taken over as maintainer of VTY 3 from Stefan O'Rear. VTY 3 already worked great and I didn't
1214really see me doing much. Still there is always something to improve. In this case vty did not
1315support the various terminals people wanted to use. And characters that occupy multiple output
1416columns were causing corruption.
1517
16−Plus, optimization is always fun. So trying my hands at optimizing Haskell code sounded great.
17−Especially when, for the most part, there was an already fast and already working version to compare
18−performance data against: Vty 3.
18+Plus, optimization is damn fun! Trying my hands at optimizing Haskell code sounded great. Way more
19+interesting than optimizing C++ ;-) Even better was that, for the most part, there was an already
20+fast and already working version to compare performance against: VTY 3.
1921
2022I figured low level optimization was what I should start on. Which only makes sense considering I
21−was only interested in optimization fun at the time. ;-) The result of this were much faster than
23+was only interested in optimization fun at the time. ;-) The result of this was much faster than
2224before. However, since I wasn't changing the design in any significant fashion some optimizations
23−could not be implemented. In the end this route was only useful to define reasonable performance
24−goals for a rewritter output layer.
25+could not be implemented. In the end this route was only useful to define performance goals for a rewritten
26+output layer.
2527
2628In addition I was learning Mandarin at the time. I wanted to, of course, create software to help me
2729study. Since I have an infatuation with terminal user interfaces I wanted a terminal library that
28−could handle double-width characters. I couldn't see an effective way to implement this with vty 3's
30+could handle double-width characters. There was no reasonable way to implement this with VTY 3's
2931implementation.
3032
31−Anybody who has needed to reimplement, or deal with the horrors of a botch reimplementation, knows
32−how dangerous this can be. A botched reimplementation ends up costing more than continueing to
33−maintain the old implementation. A reimplementation is only feasable if the immediate cost of
34−performing the work is offset by the profits the improvements provide.
35−
36−A particular source of trouble for vty was the insanity of dealing with terminals or terminal
37−emulators. I'm never going to refer to the physical box of relays from the 70s and 80s that is
38−properly called a terminal again. Terminal emulators are now be refered to as terminals and the
39−others don't exist. So...
40−
41−Terminals are software driven character displays and a keyboard. The software controls the diplay by
42−serializing to the STDOUT UTF-8 byte character sequences. Which are then displayed. And control
43−codes which modify the display of the characters. Input from the keyboard and events are read from
44−STDIN.
45−
46−Why the fuck something as old as a terminal hasn't been beaten down into a simple, universally
47−supported set of operations by now is a mystery. I don't think curses are terminfo count. I suspect
48−if support for everything that cannot support the required interface is dropped things would only be
49−better. For this reason I only focused on supporting the following terminals: xterm-256-color with
50−UTF-8; Mac OS X Terminal.app; gnome terminal, kde terminal; and rxvt-unicode. Basically: All the
51−terminals I could easily use and behaved close to how I expected.
52−
53−While I did not consider supporting the Windows platform I hoped that the abstractions used to
54−handle the various non-Windows terminals would simplify supporting Windows in the future.
55−
5633To assure the re-implementation did not introduce regressions I repeatedly:
57340. Characterized vty 3's implementation. Both in terms of functionality and performance.
58351. Defined the semantics for the new implementation.
@@ -87,21 +64,53 @@ I used a very simple Makefile to manage the execution of tests. The usage follow
8764 directory. The results included a time and memory profile.
8865Nothing fancy, but enough to support a very quick modify/test cycle.
8966
90−Compared to VTY 3 the optimization of VTY 4 was easier. Each test provided basic performance
91−feedback in addition to verifying correctness. I investigated significant changes in the performance
92−data and, for each case, determined if the change was acceptable or indicated a performance
93−regression. Any change in performance that was due to correcting the implementation was considered
94−acceptable. This is in contrast to VTY 3 where all the optimizations in the final release were
95−micro-optimizations: Hand application of primitive types and equations.
67+As mentioned before, a particular source of trouble was the insanity of dealing with different
68+terminals or terminal emulators.
9669
97−Sun Jan 11 13:37 2009 Time and Allocation Profiling Report (Final)
98−total time = 3.48 secs (174 ticks @ 20 ms)
99−total alloc = 2,542,866,800 bytes (excludes profiling overheads)
70+First off: I'm never going to refer to the physical box of relays from the 70s and 80s that is
71+properly called a "terminal" again. "Terminal emulators" are now be refered to as terminals and the
72+others should be archived and forgotten. So...
10073
101−Current release of Vty with minimal use of primitive types but an entirely different algorithm:
102−
103−Thu Sep 3 13:30 2009 Time and Allocation Profiling Report (Final)
104−total time = 1.84 secs (92 ticks @ 20 ms)
105−total alloc = 1,513,254,136 bytes (excludes profiling overheads)
74+Terminals are software driven character displays paired with keyboard input. The software controls
75+the diplay by serializing to the STDOUT UTF-8 byte character sequences. Which are then displayed.
76+And control bytes which modify the state of the terminal. Input from the keyboard and events are
77+read from STDIN.
10678
79+Why the fuck something as old as a terminal hasn't been beaten down into a simple, universally
80+supported set of operations by now is a mystery. And no, curses and terminfo are not simple. I
81+suspect if support for everything that does no support a reasonable interface is dropped things
82+would only be better. For this reason I only focused on supporting the following terminals:
83+xterm-256-color with UTF-8; Mac OS X Terminal.app; gnome terminal, kde terminal; and rxvt-unicode -
84+All the terminals I could easily use and behaved how I wanted.
85+
86+Reliably optimizing VTY 4 was simple. The only optimizations I applied were to reach the goal that
87+nothing, once verified, got slower during further development. Each test provided basic performance
88+feedback in addition to verifying correctness. Such as a time and memory profile. I investigated
89+significant changes in the performance data and, for each case, determined if the change was
90+acceptable or indicated a performance regression. However, any change in performance that was done
91+to correct the implementation was considered acceptable. All this is quite different from my
92+optimization work on VTY 3. In VTY 3 all the optimizations in the final release were
93+micro-optimizations: Hand application of primitive types and equations. Which were difficult to
94+verify compared to VTY 4's optimizations.
95+
96+One source of VTY 4's speed was the use of a different serialization algorithm than VTY 3. VTY 3
97+serialized bytes to the terminal an operation at a time. This resulted in either too many IO
98+operations or too many memory allocations. So for VTY 4 the output algorithm had the goals to batch
99+operations and not perform (any) memory allocation during serialization. Output was serialized to a fixed sized buffer then the buffer was
100+output. While fast, to do this correctly the required buffer size must be known before
101+serialization. This could be implemented performing a fold on the same output strucuture.
102+The only test that performed the equivalent operations under VTY 3 and VTY 4 was the basic benchmark
103+test. For VTY 3 the best results were:
104+ total time = 3.48 secs (174 ticks @ 20 ms)
105+ total alloc = 2,542,866,800 bytes (excludes profiling overheads)
106+
107+For VTY 4 the results are:
108+ total time = 1.84 secs (92 ticks @ 20 ms)
109+ total alloc = 1,513,254,136 bytes (excludes profiling overheads)
110+
111+Both execution time and allocations were greatly reduced. A definite win!
112+
113+Everything in this project went better than I expected except, of course, the release took longer
114+than expected. Ah well! I am more convinced than before that Haskell can provide a powerful
115+systems programming environment.
107116