His root element is "". I'm not aware of the dl attribute even existing... Is that for compressibility or does the "dl" actually do something?
As much Stack Overflow as possible in 4096 bytes
61–70 of 77 posts
Re: As much Stack Overflow as possible in 4096 bytes
#62Some of the workarounds he mentions at the end of his Trello in 4096 bytes[1] post seem really interesting: - I optimized for compression by doing things the same way everywhere; e.g. I always put the class attribute first in my tags - I wrote a utility that tried rearranging my CSS, in an attempt to find the ordering that was the most compressible [1] http://danlec.com/blog/trello-in-4096-bytes
It sounds like the goal was to reduce the entropy of the code as much as possible, to within whatever the windows of the algorithm were set to. I've seen similar ideas in the demoscene 4k competition world, where code and music is arranged to have as many repeating self-similar patterns as possible so the executable compressors can shrink them optimally.
...and reordering vertex data in chunks of only x-coords followed by chunks of y-coords followed by z-coords for the same reasons.
"Farbrausch" and their series of Fr-X "small" demos would be one example of this kind of "entropy trickery"
http://www.pouet.net/groups.php?which=322
The next target for crunching would be to minimize the actual amount of code given to the browser to execute, versus maximizing the compression ratio only (which is "just" correlated to the running "code" size)
Re: As much Stack Overflow as possible in 4096 bytes
#63And now consider that 4096 bytes (words) was exactly the total memory of a DEC PDP-1, considered to be a mainframe in its time and featuring timesharing and things like Spacewar!. And now we're proud to have a simple functional list compiled into the same amount of memory ...
Your iPhone also had more computing power than the rest of the world. Combined! :-)
And it even can play Bach and connect to the network, like the PDP-1! :-)
Re: As much Stack Overflow as possible in 4096 bytes
#64Very impressive. I wish extreme performance goals and requirements would become a new trend. I think we have come to accept a certain level of sluggishness in web apps. I hate it. I wrote a tire search app a few years back and made it work extremely fast given the task at hand. But I did not go to the level that this guy did. http://tiredb.com
> I wish extreme performance goals and requirements would become a new trend. Well, there will always be demoscene ( http://www.youtube.com/watch?v=5lbAMLrl3xI ) which I've always found remarkable.
The Windows demos almost always use a lot of the system libraries for the bulk of their work., which hasn't impressed me quite as much as what you can do in 4k with bare DOS --- where the code is directly manipulating the hardware. No libraries, no GPU drivers:
Re: As much Stack Overflow as possible in 4096 bytes
#65Very impressive. I wish extreme performance goals and requirements would become a new trend. I think we have come to accept a certain level of sluggishness in web apps. I hate it. I wrote a tire search app a few years back and made it work extremely fast given the task at hand. But I did not go to the level that this guy did. http://tiredb.com
> I wish extreme performance goals and requirements would become a new trend.
Not just performance, but efficiency - both speed and size. Sadly it seems that most of the time this point is brought up, it gets dismissed as "premature optimisation". Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not care much about efficiency "because hardware is always getting better". I've never agreed with that sort of thinking.
I think it creates a skewed perception of what can be accomplished with current hardware, since it makes optimisation an "only if it's not fast/small enough/we can't afford new hardware" goal; it won't be part of the mindset when designing, nor when writing the bulk of the code. The demoscene challenges this type of thought; it shows that if you design with specific size/speed goals in mind, you can achieve what others would have thought to be impossible. I think that's a real eye-opener; by pushing the limits, it's basically saying just how extremely inefficient most software is.
Re: As much Stack Overflow as possible in 4096 bytes
#66There seems to be many bytes left! :) $ zopfli -c st4k |wc 11 127 4050
Thanks for the pointer to zopfli. I've used p7zip in the past as a "better gzip", and it gets good results for this one too :D
$ curl -s http://danlec.com/st4k | gzip -cd | 7z a -si -tgzip -mx=9 compressed.gz
$ wc compressed.gz
14 84 4048 compressed.gzRe: As much Stack Overflow as possible in 4096 bytes
#67First off, nice work. I've noticed that St4k is loading each thread using ajax, where-as stackoverflow actually opens a new 'page', reloading a lot of webrequests. Disclaimer I've got browser cache disabled. E.g on a thread click: St4k: GET https://api.stackexchange.com/2.2/questions/21840919 [HTTP/1.1 200 OK 212ms] 18:02:16.802 GET https://www.gravatar.com/avatar/dca03295d2e81708823c5bd62e75... [HTTP/1.1 200 OK 146m…
Almost all that really tells us is that you have browser cache disabled (resources such as jquery wouldn't be re-requested on StackOverflow is you didn't). As a matter of interest, why are you disabling browser cache? Doesn't that waste a needless amount of bandwidth? Is it for some kind of security reason?
Re: As much Stack Overflow as possible in 4096 bytes
#68Very impressive. I wish extreme performance goals and requirements would become a new trend. I think we have come to accept a certain level of sluggishness in web apps. I hate it. I wrote a tire search app a few years back and made it work extremely fast given the task at hand. But I did not go to the level that this guy did. http://tiredb.com
> I wish extreme performance goals and requirements would become a new trend. Not just performance, but efficiency - both speed and size. Sadly it seems that most of the time this point is brought up, it gets dismissed as "premature optimisation". Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not c…
> Instead we're taught in CS to pile abstraction upon abstraction even when they're not really needed, to create overly complex systems just to perform simple tasks, to not care much about efficiency "because hardware is always getting better". I've never agreed with that sort of thinking.
Right, exactly. It's obvious too that software has scaled faster than hardware in the sense that to do an equivalent task like say, boot to a usable state, takes orders of magnitude longer today than it it used to, despite having hardware that's also orders of magnitude faster.
So when I see demo of ported software that does something computing used to do back in the 90s (but slowly), I'm really only impressed by the massive towers of abstraction we're building on these days, but what we're actually able to do is not all that much better. To think that I'm sitting on a machine capable of billions of instructions per second, and I'm watching it perform like a computer doing millions, is frankly depressing.
All of this is really to make the programmers more efficient, because programmer time is expensive (and getting stuff out the door quicker is important), but the amount of lost time (and money) on the user's end, waiting for these monstrosities of abstraction to compute something must far far exceed those costs.
I'm actually of the opinion that developers should work on or target much lower end machines to force them to think of speed and memory optimizations. The users will thank them and the products will simply "be better" and continue to get better as machines get better automatically.
Re: As much Stack Overflow as possible in 4096 bytes
#69First off, nice work. I've noticed that St4k is loading each thread using ajax, where-as stackoverflow actually opens a new 'page', reloading a lot of webrequests. Disclaimer I've got browser cache disabled. E.g on a thread click: St4k: GET https://api.stackexchange.com/2.2/questions/21840919 [HTTP/1.1 200 OK 212ms] 18:02:16.802 GET https://www.gravatar.com/avatar/dca03295d2e81708823c5bd62e75... [HTTP/1.1 200 OK 146m…
Almost all that really tells us is that you have browser cache disabled (resources such as jquery wouldn't be re-requested on StackOverflow is you didn't). As a matter of interest, why are you disabling browser cache? Doesn't that waste a needless amount of bandwidth? Is it for some kind of security reason?
I'm currently developing a lot of websites. Disabling browser cache ensures that every file is the most resent version (and not cached), as well as to better see dependency loading.
Even with browser cache enabled, stack overflow loads a considerable number of resources compared to st4k. St4k loads 1 api call to get the S.O. data (JSON - ~1KiB), then loads any needed images. Stack overflow is loading the entire HTML document again (~15KiB), along with a lot of other web resources. Without going into their code, I've got no idea on what is lazy loading.
But my point still stands on the speed of page navigation (not first time landing). St4k is faster as each change of page requires less KiBs of information to perform a page render, as well as less content to render: Compressed JSON, vs the entire HTML markup, and Rendering the Changes vs Re-Rendering the entire window/document.
Re: As much Stack Overflow as possible in 4096 bytes
#70Earlier quoted context omitted.
the "sufficiently smart compiler" is kind of like "world peace"; something to work towards, but i doubt we'll have it this lifetime. http://c2.com/cgi/wiki?SufficientlySmartCompiler
"Sufficiently Smart Compiler", like most AI, is a concept with constantly shifting goal-posts. As soon as compilers can do something, we no longer consider that thing "smart." Consider variable lifetime analysis, or stream fusion -- a decade ago, these would be considered "sufficiently smart compiler" features. Today, they're just things we expect (of actually-decent compilers), and "sufficiently smart" means somethi…
And, given those optimizations, the programmers get sufficiently dumber to compensate, resulting in a constant or decreasing level of performance.
That's gotta be a law codified somewhere, right?