And with this, I hope we'll see a race for GC pauses improvements.
Go GC: Solving the Latency Problem in Go 1.5
21–30 of 132 posts
Re: Go GC: Solving the Latency Problem in Go 1.5
#22> ...there has been a virtuous cycle between software and hardware development. CPU hardware improves, which enables faster software to be written, which in turn... This is the exact opposite of the experience I've had with (most) software. A new CPU with a higher clock speed makes existing software faster, but most new software written for the new CPU will burn all of the extra CPU cycles on more layers of abstracti…
I know it's a common complaint amongst a certain set to remember some bizarre version of the good old days when software was lean and mean and usable and did all the work our modern software does, but that time literally never existed. What you call bloat, most people either call "usability and features" or simply don't notice at all. The fact that you (apparently) don't like usability and features and prefer to call…
That's not true. There are many websites today that have identical or less functionality than in the past, and they're just SLOW. So many sites I visit do an inane amount of work to load up a static site. And they scroll poorly, they feel laggy. There's no new functionality, except as far as the developer goes - they're now doing databinding on the client, loading content at runtime (vs sending back rendered HTML), etc.
Edit: I'd also add "on the web" continues to be an excuse for slow, unresponsive software. Even in ~96 or so, I remember folks getting excited. "Look at this online frog dissection thing!" ... It was crappier than what you could do with even a small download. But it was on the web so it was hot. Same thing now.
Re: Go GC: Solving the Latency Problem in Go 1.5
#23Earlier quoted context omitted.
> and took half as much time to develop Abstractions make coding faster now?
Isn't that the point? Why else use abstractions if not to make yourself more productive?
Well if I asked your average brain-dead Java developer it would be to make your code more "generic" so you don't have to change a single line of code when requirements change, just tweak some XML somewhere!
And if there is one thing that Java developers are not, it is productive. I will usually be finishing off a project in Python while they are still coding getters/setters on their AbstractProxyFactoryFactory class.
Re: Go GC: Solving the Latency Problem in Go 1.5
#24Earlier quoted context omitted.
> and took half as much time to develop Abstractions make coding faster now?
No, it'd be way faster to just do it all in assembly. These fancy "high level languages" and "memory management" and "libraries" are just cons foisted on poor unsuspecting programmers by middle management and enthusiastic marketers. Real Programmers (TM) don't need any of that shit. (/s)
You don't seem to understand what "abstraction" means in computer science. Hint: it's nothing to do with memory management. High level languages like Python/Ruby actually have less abstractions than lower level languages like Java because they don't need them, and Python/Ruby programmers tend to want to get stuff done rather than write a ode to the Gang of 4 in XML.
Re: Go GC: Solving the Latency Problem in Go 1.5
#25> ...there has been a virtuous cycle between software and hardware development. CPU hardware improves, which enables faster software to be written, which in turn... This is the exact opposite of the experience I've had with (most) software. A new CPU with a higher clock speed makes existing software faster, but most new software written for the new CPU will burn all of the extra CPU cycles on more layers of abstracti…
It's probably fair to call that a reasonable characterization of the Go's "home problem domain", though. Contrary to popular belief that "cloud" means you can just write crappy code and throw cheap hardware at it, when you are truly working at cloud scale you actually try to write software as lean and mean as possible, because everybody cares about 10x and 100x differences in the amount of hardware that a particular cloud service takes.
Yes, desktops continue to be gluttonous hogs, because you'd rather have your software now than glorious software three years from now (which you can't have anyhow because the company went out of business trying to polish it instead of releasing it). Lately "mobile" is really pushing it, I think. But in Go's wheelhouse, efficiency has actually manifested.
I've often thought that the there is less difference than you'd think between embedded programming and cloud programming; both groups of programmers may literally be counting cycles and watching their L1 caches. It's those in the middle who have more power sitting around than they know what to do with who can afford to be a bit "lazy".
Re: Go GC: Solving the Latency Problem in Go 1.5
#26Earlier quoted context omitted.
I know it's a common complaint amongst a certain set to remember some bizarre version of the good old days when software was lean and mean and usable and did all the work our modern software does, but that time literally never existed. What you call bloat, most people either call "usability and features" or simply don't notice at all. The fact that you (apparently) don't like usability and features and prefer to call…
That's not true. There are many websites today that have identical or less functionality than in the past, and they're just SLOW. So many sites I visit do an inane amount of work to load up a static site. And they scroll poorly, they feel laggy. There's no new functionality, except as far as the developer goes - they're now doing databinding on the client, loading content at runtime (vs sending back rendered HTML), e…
It could still be a case of one person's bloat being another's feature. Though for a website website, the other people could be advertisers, people who develop the site and people who publish content to it. There was a Mozilla report not too long ago that found that just disabling tracking (not ads) reduced page load times by almost half.
Re: Go GC: Solving the Latency Problem in Go 1.5
#27Earlier quoted context omitted.
Have you encountered any problems with go GC pauses?
Yes, I have. We used go in a system that had to keep track of essentially large hashes containing popularity / scoring information, in addition to what were effectively routing tables, and ran into >500ms pauses. At scale, it seemed the largest part of the complexity of go was manipulating data structures and code to avoid gc pauses. With sufficient work we may have been able to decrease the pauses sufficiently, but…
If it's possible, and you're interested in trying, it would be interesting to pull that code out and try it again with Go 1.5, if it's easy.
If you've got a C++ solution, I would not suggest under any circumstances short of Go suddenly and frankly mysteriously blowing the doors off of C++ that you switch... I'm just saying it would be an interesting comparison.
Re: Go GC: Solving the Latency Problem in Go 1.5
#28Earlier quoted context omitted.
I know it's a common complaint amongst a certain set to remember some bizarre version of the good old days when software was lean and mean and usable and did all the work our modern software does, but that time literally never existed. What you call bloat, most people either call "usability and features" or simply don't notice at all. The fact that you (apparently) don't like usability and features and prefer to call…
That's not true. There are many websites today that have identical or less functionality than in the past, and they're just SLOW. So many sites I visit do an inane amount of work to load up a static site. And they scroll poorly, they feel laggy. There's no new functionality, except as far as the developer goes - they're now doing databinding on the client, loading content at runtime (vs sending back rendered HTML), e…
Websites are a great example since the bloat is clearly visible on the developer's end. I decided to try using Foundation last week. The last time I worked on a website I just generated some static HTML markup and filled it in with my own hand-built CSS. Nobody would give an award for that design, but it was functional enough.
The Foundation install instructions first ask for three dependencies: Ruby, node.js, and git. Subsequently, through gem and npm, dozens of other dependencies were installed. The framework pushes multiple .js dependencies onto the served pages, and heavily encourages using either Compass or libsass to generate the final CSS, making it weigh considerably more. It even had tooling to automatically rebuild as a background process.
All of this, and I basically just modified the example templates slightly to help me build a layout. In theory all sorts of other things could be done with that framework, but the nature of the software stack we have, at least in this domain, favors including the kitchen sink when you need a cup of water.
Re: Go GC: Solving the Latency Problem in Go 1.5
#29Earlier quoted context omitted.
That's not true. There are many websites today that have identical or less functionality than in the past, and they're just SLOW. So many sites I visit do an inane amount of work to load up a static site. And they scroll poorly, they feel laggy. There's no new functionality, except as far as the developer goes - they're now doing databinding on the client, loading content at runtime (vs sending back rendered HTML), e…
It could still be a case of one person's bloat being another's feature. Though for a website website, the other people could be advertisers, people who develop the site and people who publish content to it. There was a Mozilla report not too long ago that found that just disabling tracking (not ads) reduced page load times by almost half.
In many cases it's not. In fact I've recently worked on several projects where the frontend is stupidly heavy for zero reason. Just sloppy or over engineered code.
I know the full extent of the capabilities - one is just a corporate website with no interactivity. It's just dumb. The previous version was just simple static HTML; but as part of the "responsive design overhaul" it turned into this behemoth that makes several dozen requests to open the homepage. Nuts.
Re: Go GC: Solving the Latency Problem in Go 1.5
#30Earlier quoted context omitted.
That's not true. There are many websites today that have identical or less functionality than in the past, and they're just SLOW. So many sites I visit do an inane amount of work to load up a static site. And they scroll poorly, they feel laggy. There's no new functionality, except as far as the developer goes - they're now doing databinding on the client, loading content at runtime (vs sending back rendered HTML), e…
Websites are a great example since the bloat is clearly visible on the developer's end. I decided to try using Foundation last week. The last time I worked on a website I just generated some static HTML markup and filled it in with my own hand-built CSS. Nobody would give an award for that design, but it was functional enough. The Foundation install instructions first ask for three dependencies: Ruby, node.js, and gi…
Don't start on node. A dozen thousand files of dependencies because every function needs its own module containing at least 6 files. And using RequireJS, well it takes 30s+ to build this site even though it's not doing anything earth shattering. And that's before running uglify or any such minimizer. I don't get it.