| … | … | @@ -8730,7 +8730,7 @@ Well, |
| 8730 | 8730 | Interesting. |
| 8731 | 8731 | This is not impractical, |
| 8732 | 8732 | either, |
| 8733 | | it's a realtively easy project, |
| 8733 | it's a relatively easy project, |
| 8734 | 8734 | even, |
| 8735 | 8735 | to implement this. |
| 8736 | 8736 | Huh. |
| … | … | @@ -8742,6 +8742,295 @@ Break for dinner. |
| 8742 | 8742 | The meta issue is ... |
| 8743 | 8743 | \end_layout |
| 8744 | 8744 | |
| 8745 | \begin_layout Standard |
| 8746 | There are two meta–issues. |
| 8747 | Or maybe the same meta–issue? |
| 8748 | Hmm. |
| 8749 | So one idea is that there exists a |
| 8750 | \begin_inset Quotes eld |
| 8751 | \end_inset |
| 8752 | |
| 8753 | natural transform |
| 8754 | \begin_inset Quotes erd |
| 8755 | \end_inset |
| 8756 | |
| 8757 | between doing loop contents serially, |
| 8758 | and doing it in parallel. |
| 8759 | |
| 8760 | \begin_inset Quotes eld |
| 8761 | \end_inset |
| 8762 | |
| 8763 | Natural transform |
| 8764 | \begin_inset Quotes erd |
| 8765 | \end_inset |
| 8766 | |
| 8767 | in some vague category–theoretic sense. |
| 8768 | For Atomese, |
| 8769 | this would be the transformation between (Trigger (FooLink ...)) and (Trigger (CollectionOf (Type 'ParallelLink) (FooLink ...))) Both do |
| 8770 | \begin_inset Quotes eld |
| 8771 | \end_inset |
| 8772 | |
| 8773 | the same thing |
| 8774 | \begin_inset Quotes erd |
| 8775 | \end_inset |
| 8776 | |
| 8777 | ; |
| 8778 | the first one does it serially, |
| 8779 | the second in parallel. |
| 8780 | So if I have a graph–rewriting system, |
| 8781 | I can rewrite the first into the second, |
| 8782 | or the second into the first. |
| 8783 | So the meta issue is this: |
| 8784 | |
| 8785 | \begin_inset Quotes eld |
| 8786 | \end_inset |
| 8787 | |
| 8788 | What is the current set of rewrite rules that I am willing to apply to a processing pipeline? |
| 8789 | \begin_inset Quotes erd |
| 8790 | \end_inset |
| 8791 | |
| 8792 | and |
| 8793 | \begin_inset Quotes eld |
| 8794 | \end_inset |
| 8795 | |
| 8796 | Should these rewrite rules create pressure for more parallelism, |
| 8797 | or less? |
| 8798 | \begin_inset Quotes erd |
| 8799 | \end_inset |
| 8800 | |
| 8801 | And there's even a regulatory component: |
| 8802 | |
| 8803 | \begin_inset Quotes eld |
| 8804 | \end_inset |
| 8805 | |
| 8806 | Apply rewrite rules to pressure the system to run on the GPU's, |
| 8807 | unless the GPU's are congested, |
| 8808 | or the PCIe bus is congested, |
| 8809 | in which case, |
| 8810 | run things locally on the CPU. |
| 8811 | \begin_inset Quotes erd |
| 8812 | \end_inset |
| 8813 | |
| 8814 | Then the complexity spirals out of control: |
| 8815 | |
| 8816 | \begin_inset Quotes eld |
| 8817 | \end_inset |
| 8818 | |
| 8819 | to know if the PCIe bus is congested, |
| 8820 | I need a sensor to measure traffic and congestion in real time |
| 8821 | \begin_inset Quotes erd |
| 8822 | \end_inset |
| 8823 | |
| 8824 | . |
| 8825 | \end_layout |
| 8826 | |
| 8827 | \begin_layout Standard |
| 8828 | And then it is recursive: |
| 8829 | |
| 8830 | \begin_inset Quotes eld |
| 8831 | \end_inset |
| 8832 | |
| 8833 | if I have sensors that can measure different aspects of system performance, |
| 8834 | then I can write some optimization algo that uses those sensor inputs. |
| 8835 | \begin_inset Quotes erd |
| 8836 | \end_inset |
| 8837 | |
| 8838 | Right? |
| 8839 | But what is the algo? |
| 8840 | Maybe there are several algos: |
| 8841 | |
| 8842 | \begin_inset Quotes eld |
| 8843 | \end_inset |
| 8844 | |
| 8845 | Performance |
| 8846 | \begin_inset Quotes erd |
| 8847 | \end_inset |
| 8848 | |
| 8849 | and |
| 8850 | \begin_inset Quotes eld |
| 8851 | \end_inset |
| 8852 | |
| 8853 | PowerSave |
| 8854 | \begin_inset Quotes erd |
| 8855 | \end_inset |
| 8856 | |
| 8857 | . |
| 8858 | What are the component pieces–parts of such an algo, |
| 8859 | and what are all the different ways that I can assemble and re–assemble those pieces–parts? |
| 8860 | Well, |
| 8861 | the pieces–parts are jigsaws, |
| 8862 | and the sensory pipeline is |
| 8863 | \begin_inset Quotes eld |
| 8864 | \end_inset |
| 8865 | |
| 8866 | PCI congestion sensor -> X |
| 8867 | \begin_inset Quotes erd |
| 8868 | \end_inset |
| 8869 | |
| 8870 | and |
| 8871 | \begin_inset Quotes eld |
| 8872 | \end_inset |
| 8873 | |
| 8874 | if X then Y |
| 8875 | \begin_inset Quotes erd |
| 8876 | \end_inset |
| 8877 | |
| 8878 | and |
| 8879 | \begin_inset Quotes eld |
| 8880 | \end_inset |
| 8881 | |
| 8882 | Y -> execute locally |
| 8883 | \begin_inset Quotes erd |
| 8884 | \end_inset |
| 8885 | |
| 8886 | but in between X and Y I can insert other kinds of control blocks: |
| 8887 | |
| 8888 | \begin_inset Quotes eld |
| 8889 | \end_inset |
| 8890 | |
| 8891 | If X>250 and X<500 then Y |
| 8892 | \begin_inset Quotes erd |
| 8893 | \end_inset |
| 8894 | |
| 8895 | or it there is another sensor Z for memory pressure, |
| 8896 | then |
| 8897 | \begin_inset Quotes eld |
| 8898 | \end_inset |
| 8899 | |
| 8900 | if X>500 and Z<90 then Y |
| 8901 | \begin_inset Quotes erd |
| 8902 | \end_inset |
| 8903 | |
| 8904 | . |
| 8905 | So my toolkit is a box of Lego MindStorms and I can snap and assemble them any way I want, |
| 8906 | as long as some basic grammatical rules are obeyed. |
| 8907 | Writing down the grammatical rules is ... |
| 8908 | well, |
| 8909 | |
| 8910 | \begin_inset Quotes eld |
| 8911 | \end_inset |
| 8912 | |
| 8913 | easy |
| 8914 | \begin_inset Quotes erd |
| 8915 | \end_inset |
| 8916 | |
| 8917 | or |
| 8918 | \begin_inset Quotes eld |
| 8919 | \end_inset |
| 8920 | |
| 8921 | easy-ish |
| 8922 | \begin_inset Quotes erd |
| 8923 | \end_inset |
| 8924 | |
| 8925 | or |
| 8926 | \begin_inset Quotes eld |
| 8927 | \end_inset |
| 8928 | |
| 8929 | a well defined problem that we know how to solve |
| 8930 | \begin_inset Quotes erd |
| 8931 | \end_inset |
| 8932 | |
| 8933 | . |
| 8934 | But the meta–issue is |
| 8935 | \begin_inset Quotes eld |
| 8936 | \end_inset |
| 8937 | |
| 8938 | what sort of proccess control system should I build? |
| 8939 | \begin_inset Quotes erd |
| 8940 | \end_inset |
| 8941 | |
| 8942 | Should it be simple? |
| 8943 | Complicated? |
| 8944 | where is the trade–off between simple and complicated? |
| 8945 | \end_layout |
| 8946 | |
| 8947 | \begin_layout Standard |
| 8948 | In the sand–pile model, |
| 8949 | I have gravity, |
| 8950 | which is the force causing avalanches, |
| 8951 | and finite slip, |
| 8952 | friction coefficients (the sand grains are not infinitely sticky) so the avalanches must necessarily occur. |
| 8953 | Even if the sand–grains are replaced by thistle, |
| 8954 | there is only so high you can go with a tower of sticky thistle before it falls over. |
| 8955 | How do I port over this conception to algorithm–building? |
| 8956 | When does an algorithm become |
| 8957 | \begin_inset Quotes eld |
| 8958 | \end_inset |
| 8959 | |
| 8960 | too complex |
| 8961 | \begin_inset Quotes erd |
| 8962 | \end_inset |
| 8963 | |
| 8964 | , |
| 8965 | and collapse? |
| 8966 | What drives that collapse? |
| 8967 | What is analogous to gravity? |
| 8968 | \end_layout |
| 8969 | |
| 8970 | \begin_layout Standard |
| 8971 | Related is this: |
| 8972 | |
| 8973 | \begin_inset Quotes eld |
| 8974 | \end_inset |
| 8975 | |
| 8976 | what is the algorithm that finds (optimal) algorithms? |
| 8977 | \begin_inset Quotes erd |
| 8978 | \end_inset |
| 8979 | |
| 8980 | Of course, |
| 8981 | if I did not care about |
| 8982 | \begin_inset Quotes eld |
| 8983 | \end_inset |
| 8984 | |
| 8985 | optimal |
| 8986 | \begin_inset Quotes erd |
| 8987 | \end_inset |
| 8988 | |
| 8989 | , |
| 8990 | then I could build an odometer that simply listed all of them. |
| 8991 | But if I want them to be |
| 8992 | \begin_inset Quotes eld |
| 8993 | \end_inset |
| 8994 | |
| 8995 | optimal |
| 8996 | \begin_inset Quotes erd |
| 8997 | \end_inset |
| 8998 | |
| 8999 | , |
| 9000 | I have multiple issues: |
| 9001 | |
| 9002 | \begin_inset Quotes eld |
| 9003 | \end_inset |
| 9004 | |
| 9005 | what do I mean by optimal? |
| 9006 | \begin_inset Quotes erd |
| 9007 | \end_inset |
| 9008 | |
| 9009 | and |
| 9010 | \begin_inset Quotes eld |
| 9011 | \end_inset |
| 9012 | |
| 9013 | what are the different ways I can measure optimality (space–usage, |
| 9014 | run–time, |
| 9015 | traffic congestion...)? |
| 9016 | \begin_inset Quotes erd |
| 9017 | \end_inset |
| 9018 | |
| 9019 | and |
| 9020 | \begin_inset Quotes eld |
| 9021 | \end_inset |
| 9022 | |
| 9023 | how do I limit the search space to avoid search regions that are unlikely to yield optimal algorithms? |
| 9024 | \begin_inset Quotes erd |
| 9025 | \end_inset |
| 9026 | |
| 9027 | |
| 9028 | \end_layout |
| 9029 | |
| 9030 | \begin_layout Standard |
| 9031 | S |
| 9032 | \end_layout |
| 9033 | |
| 8745 | 9034 | \begin_layout Section* |
| 8746 | 9035 | The End |
| 8747 | 9036 | \end_layout |