4 ms·

Ok, so if you understand the creation of money and you understand that google is super good at engineering, can you see the link between those two things? Belo

by bullen 10y ago

Ok, so if you understand the creation of money and you understand that google is super good at engineering, can you see the link between those two things? Below is the answer, tip no. 2 to YC: add spoiler tag. They are using their monopoly and benefits (their clients borrowed money at low interest) to build data centers that use lots of cheap finite energy instead of actually trying to innovate. The only energy added to the planet is sunrays, the only way that energy is stored is by photosyntesis, we have consumed millions of years of sunshine in 200 years. If all internet systems where async-to-async you could probably close 10 nuclear power plants immediately. (btw we only have 50 years of uranium left at this rate) Solar and wind to electrivity are net energy negative and require more fossil energy to manufacture than they deliver in their lifetime. Talk about "doing no evil".

icebraining 10y ago
Like I said, you're yet to explain what "async-to-async" actually means in this context. I say this, because I don't think you actually understand what Google means when you write that they're using a synchronous model of development. What they're doing is, quoting from the article, "shifting the burden of managing asynchronous events away from the programmer to the operating system or the thread library". The programs themselves are still asynchronous, it's just that the programmer doesn't have to care. So if you're going to claim that using a synchronous programming model over an asynchronous runtime wastes a lot of energy, you're going to have to (1) explain very well the differences between that model and the one you're proposing and (2) explain how your model wastes less energy. You're also going to have to support the rather extraordinary claim that "[s]olar and wind to electrivity are net energy negative". That myth was already false back in the late 90s, it's quite absurd nowadays. The Energy Payback time of a current solar panel is just a couple of years, depending on how sunny the place you put it is.
- bullen 10y ago
  You can't move the async without the developer touching it if you want the async to save you IO-wait = be on the socket. You need the async. to be in the network. Async-to-async means your CPU only touches your work when it has to and when the instance is waiting the work is in transit on the network so the CPU can do other things. > In practice, you need two small pools of threads with the same amount of threads as the CPU has cores. And those will pass the "work" back and forth between incoming requests -> outgoing requests and then incoming response -> outgoing response, both arrows indicating a thread to thread handover that will make most programmers faint. (but once the platform is built developers just need to wrap their head around the philosophy and not making that handover work) Async-to-async is the solution for zero IO-wait without context switching problems and scalable to millions of concurrent sockets per machine, not that that's what you want, what you want is a distributed model where many small machines co-operate on a larger task, but that requires async-to-async too. An here you have to try and use any SQL database to see why that fails in a distributed system. etc. etc. I need to write a book and I rather write software to prove my point instead. (if yc had edit after longer duration I would explain this here too later 3rd tip) When a thread is stuck in IO-wait that is pure loss, eventually all sync. systems break due to IO-wait and that means you need overcapacity. The advantage with Async. is that 100% CPU means little to no problem and you can have the system appropriately powered at all times by sharing resources in a distributed sandbox instead of sharding them in virtualboxes/containers. > Sidenote: you need to be able to share memory across threads so forget about programming languages that don't have "real" threads (PHP, Javascript, ruby, python, etc.) Overloads are fun in a async. system, because the CPU just keeps working on the queue that it fundamentally needs (that sync systems have between everything to avoid crashing) and watching the latency go up a bit when the system is overloaded is so much fun when you see the system does not grind to a halt but just churns right through the overload. > Async. is inherently anti-fragile. About solar, you need to remove money and add all energy required to build everything around the solar panel, including the energy required for the person assembling it and even that persons cat food, transport, mining, etc. Otherwise you're only seeing "the tree and not the forest". Energy has no dollar price, you should not be able to buy energy with "nothing". > The dollar does not exist. As an exercise you can read the source, and then when you feel confident enough google: async. processor. My next and last project is to apply async. to a 3D engine, where the rendering/physics is done in two c++ threads, and the scripting in java asynchronously modifies the state for those threads from a third thread.
  - icebraining 10y ago
    The way you keep extolling the virtues of asynchronous execution leads me to conclude that you don't understand Google's approach, since it is asynchronous as well. If you want to explain the actual concrete differences between your approach and theirs, feel free, otherwise there's little point is continuing this discussion.
    - bullen 10y ago
      Is it async. with one thread per "work"? If so you are in trouble. I tried to see if you can abstract async. into a sync model but you need the callback and wakeup syntax which is a dealbreaker. Google is not async the way you need async to work for it to make sense for IO-wait. What this discussion should lead to is for you to read the code and learn how async. can work. Not just to blindly follow the majority. Maybe if you like to have someone explain things; go to school, but don't take a student loan. But you are right there are a million things I'm missing to communicate, because of time and frankly I forget how it all works, intuition is very important for progress, if you had to explain everything all the time nothing would get made.
      - icebraining 10y ago
        Is it async. with one thread per "work"? If so you are in trouble. I tried to see if you can abstract async. into a sync model but you need the callback and wakeup syntax which is a dealbreaker. No, you don't need any callback syntax. You can use CSP or Actors, and there are probably other models. See Go, Limbo, Erlang, Akka, and a bunch of other languages and frameworks.
        bullen 10y ago
        Ok, tell you right now, this abstraction is overengineered (akka). My Async.java class replaces the whole framework in 750 lines of Java: http://root.rupy.se/code http://root.rupy.se/code Erlang is not a good language because it can't share memory across threads. As for Go, it doesn't have real threads that can share memory either, you can't hot-deploy it and coding non-VM languages should only be done if you need the performance (3D engine). Don't know anything about Limbo except that it probably is crummy as hell and probably suffer from the same "no real threads" syndrome. The reason you don't need callbacks is because these language ARE "callback" languages. Just like Javascript. There are only two families of real usable programming languages: native: C (C++, Rust, etc.) and VM: Java (C#, F#, etc.).

by bullen 10y ago

icebraining 10y ago

Like I said, you're yet to explain what "async-to-async" actually means in this context. I say this, because I don't think you actually understand what Google means when you write that they're using a synchronous model of development. What they're doing is, quoting from the article, "shifting the burden of managing asynchronous events away from the programmer to the operating system or the thread library". The programs themselves are still asynchronous, it's just that the programmer doesn't have to care. So if you're going to claim that using a synchronous programming model over an asynchronous runtime wastes a lot of energy, you're going to have to (1) explain very well the differences between that model and the one you're proposing and (2) explain how your model wastes less energy. You're also going to have to support the rather extraordinary claim that "[s]olar and wind to electrivity are net energy negative". That myth was already false back in the late 90s, it's quite absurd nowadays. The Energy Payback time of a current solar panel is just a couple of years, depending on how sunny the place you put it is.

bullen 10y ago
You can't move the async without the developer touching it if you want the async to save you IO-wait = be on the socket. You need the async. to be in the network. Async-to-async means your CPU only touches your work when it has to and when the instance is waiting the work is in transit on the network so the CPU can do other things. > In practice, you need two small pools of threads with the same amount of threads as the CPU has cores. And those will pass the "work" back and forth between incoming requests -> outgoing requests and then incoming response -> outgoing response, both arrows indicating a thread to thread handover that will make most programmers faint. (but once the platform is built developers just need to wrap their head around the philosophy and not making that handover work) Async-to-async is the solution for zero IO-wait without context switching problems and scalable to millions of concurrent sockets per machine, not that that's what you want, what you want is a distributed model where many small machines co-operate on a larger task, but that requires async-to-async too. An here you have to try and use any SQL database to see why that fails in a distributed system. etc. etc. I need to write a book and I rather write software to prove my point instead. (if yc had edit after longer duration I would explain this here too later 3rd tip) When a thread is stuck in IO-wait that is pure loss, eventually all sync. systems break due to IO-wait and that means you need overcapacity. The advantage with Async. is that 100% CPU means little to no problem and you can have the system appropriately powered at all times by sharing resources in a distributed sandbox instead of sharding them in virtualboxes/containers. > Sidenote: you need to be able to share memory across threads so forget about programming languages that don't have "real" threads (PHP, Javascript, ruby, python, etc.) Overloads are fun in a async. system, because the CPU just keeps working on the queue that it fundamentally needs (that sync systems have between everything to avoid crashing) and watching the latency go up a bit when the system is overloaded is so much fun when you see the system does not grind to a halt but just churns right through the overload. > Async. is inherently anti-fragile. About solar, you need to remove money and add all energy required to build everything around the solar panel, including the energy required for the person assembling it and even that persons cat food, transport, mining, etc. Otherwise you're only seeing "the tree and not the forest". Energy has no dollar price, you should not be able to buy energy with "nothing". > The dollar does not exist. As an exercise you can read the source, and then when you feel confident enough google: async. processor. My next and last project is to apply async. to a 3D engine, where the rendering/physics is done in two c++ threads, and the scripting in java asynchronously modifies the state for those threads from a third thread.
- icebraining 10y ago
  The way you keep extolling the virtues of asynchronous execution leads me to conclude that you don't understand Google's approach, since it is asynchronous as well. If you want to explain the actual concrete differences between your approach and theirs, feel free, otherwise there's little point is continuing this discussion.
  - bullen 10y ago
    Is it async. with one thread per "work"? If so you are in trouble. I tried to see if you can abstract async. into a sync model but you need the callback and wakeup syntax which is a dealbreaker. Google is not async the way you need async to work for it to make sense for IO-wait. What this discussion should lead to is for you to read the code and learn how async. can work. Not just to blindly follow the majority. Maybe if you like to have someone explain things; go to school, but don't take a student loan. But you are right there are a million things I'm missing to communicate, because of time and frankly I forget how it all works, intuition is very important for progress, if you had to explain everything all the time nothing would get made.
    - icebraining 10y ago
      Is it async. with one thread per "work"? If so you are in trouble. I tried to see if you can abstract async. into a sync model but you need the callback and wakeup syntax which is a dealbreaker. No, you don't need any callback syntax. You can use CSP or Actors, and there are probably other models. See Go, Limbo, Erlang, Akka, and a bunch of other languages and frameworks.
      - bullen 10y ago
        Ok, tell you right now, this abstraction is overengineered (akka). My Async.java class replaces the whole framework in 750 lines of Java: http://root.rupy.se/code http://root.rupy.se/code Erlang is not a good language because it can't share memory across threads. As for Go, it doesn't have real threads that can share memory either, you can't hot-deploy it and coding non-VM languages should only be done if you need the performance (3D engine). Don't know anything about Limbo except that it probably is crummy as hell and probably suffer from the same "no real threads" syndrome. The reason you don't need callbacks is because these language ARE "callback" languages. Just like Javascript. There are only two families of real usable programming languages: native: C (C++, Rust, etc.) and VM: Java (C#, F#, etc.).