The article mentions how this compression technique is similar to image compression. Would anyone care to explain, in detail if necessary, how this is so? Thanks.
Bandwidth needs halved by new compression written in Go
91–100 of 121 posts
Re: Bandwidth needs halved by new compression written in Go
#92Earlier quoted context omitted.
"write a memory recycler" sigh This is by far go's biggest wart IMO, and one that frequently sends me back to a pauseless (hah! at least less pausy:) systems language. I sure do like it in almost every other meaningful regard. But I wish latency wasn't something the designers punted on.
I occasionally hear this kind of complaint, but I've yet to see any silver-bullet memory management system. AFAICT, the best we've been able to accomplish is to provide a easier path to correctness with decent overall performance. Also, GC latency isn't the only concern. As soon as the magic incantation "high performance" is uttered, all bets are off. There's been decades of work on real-time garbage collection yet a…
I can't speak for the grandparent, but for my part I agree with your point that allocation patterns matter and that there is no silver bullet to memory management, which is exactly the reason that GC'd languages like Go are uninteresting as systems languages. Why use a language where you have to work around one of its main features when you care about performance?
I find Rust's approach much more interesting, because GC is entirely optional, but it provides abstractions that make it easier to write clear and correct manual memory management schemes.
Re: Bandwidth needs halved by new compression written in Go
#93Earlier quoted context omitted.
"write a memory recycler" sigh This is by far go's biggest wart IMO, and one that frequently sends me back to a pauseless (hah! at least less pausy:) systems language. I sure do like it in almost every other meaningful regard. But I wish latency wasn't something the designers punted on.
I occasionally hear this kind of complaint, but I've yet to see any silver-bullet memory management system. AFAICT, the best we've been able to accomplish is to provide a easier path to correctness with decent overall performance. Also, GC latency isn't the only concern. As soon as the magic incantation "high performance" is uttered, all bets are off. There's been decades of work on real-time garbage collection yet a…
"AFAICT, the best we've been able to accomplish is to provide a easier path to correctness with decent overall performance."
Precisely. Which is why for performance-critical systems code it's important to give the programmer the choice of memory allocation techniques, but to add features to the language to make memory use safer.
Garbage collection is great, but occasionally it falls down and programmers have to resort to manual memory pooling. Then it becomes error-prone (use after free, leaks) without type system help such as regions and RAII.
Re: Bandwidth needs halved by new compression written in Go
#94FTA: "If it was written in C++, it would be threaded code" Uh, why?
Because that’s one approach to getting the most out of all of those multiple core CPU servers.
For Go that came for free because its Communicating Sequential Processes design does that for you.
Re: Bandwidth needs halved by new compression written in Go
#95Earlier quoted context omitted.
I occasionally hear this kind of complaint, but I've yet to see any silver-bullet memory management system. AFAICT, the best we've been able to accomplish is to provide a easier path to correctness with decent overall performance. Also, GC latency isn't the only concern. As soon as the magic incantation "high performance" is uttered, all bets are off. There's been decades of work on real-time garbage collection yet a…
I can't speak for the grandparent, but for my part I agree with your point that allocation patterns matter and that there is no silver bullet to memory management, which is exactly the reason that GC'd languages like Go are uninteresting as systems languages. Why use a language where you have to work around one of its main features when you care about performance? I find Rust's approach much more interesting, because…
Hm, Rust keeps hitting my radar with interesting attributes like this. Time to go have a look see. Thanks!
Re: Bandwidth needs halved by new compression written in Go
#96> Today, [cloud providers Amazon Web Services and Rackspace, and thirty of the world’s biggest Web hosting companies] announced that they will support Railgun...
I can't find any such announcements; anybody have links? Based on comments further down, I wonder if the author is confused.
> CloudFlare will provide software images for Amazon and RackSpace customers to install
That is very different from the claim in the first paragraph.
Re: Bandwidth needs halved by new compression written in Go
#97> Today, [cloud providers Amazon Web Services and Rackspace, and thirty of the world’s biggest Web hosting companies] announced that they will support Railgun... I can't find any such announcements; anybody have links? Based on comments further down, I wonder if the author is confused. > CloudFlare will provide software images for Amazon and RackSpace customers to install That is very different from the claim in the…
Amazon and Rackspace customers need to install the software themselves (for now). The other listed hosts have made it one-click simple without the customer having to install anything. A couple announcements from major hosts today:
Dreamhost: http://dreamhost.com/dreamscape/2013/02/26/cloudflare-railgu... Media Temple: http://weblog.mediatemple.net/2013/02/26/the-web-just-got-fa...
Re: Bandwidth needs halved by new compression written in Go
#98Earlier quoted context omitted.
I'm curious, if you can get things done more quickly in Go, why do you feel C++ is generally a better choice? Performance?
For me, I just don't see enough benefits of Go over C++. I already know how to use C++ in a way that avoids or mitigates the problems Go solves. With C++11 support starting to take off Go's advantages are even smaller. On the other hand, if I didn't know C++ and I was looking for a native compiled language to learn, I'd probably choose Go over C++.
Depending on what you're doing, the libraries make a giant difference. Look over Go's standard library packages and then imagine what a pain in the ass it would be to find and manage all the separate C/C++ libs it would take to replicate all that functionality (or to write it yourself).
Re: Bandwidth needs halved by new compression written in Go
#99I see that the article is tagged "open source." Is CloudFront going to open source Railgun? Publish any papers?
This isn't an announcement about companies supporting Railgun...it's about companies supporting CloudFlare by installing the Railgun Listener.
Re: Bandwidth needs halved by new compression written in Go
#100FTA: "If it was written in C++, it would be threaded code" Uh, why?
Because that’s one approach to getting the most out of all of those multiple core CPU servers. For Go that came for free because its Communicating Sequential Processes design does that for you.
Came for free? Go takes advantage of multiple cores by using threads. CSP doesn't magically multiplex your code onto your cores.