hermanhermitage

17 ms·

121.
by hermanhermitage 14y ago
Interesting. I hear what you are saying. To contradict everything I've said elsewhere on compatibility - I'm actually in favor of the 1.0/1.1 OpenGL ES standards and would have liked WebGL to offer 1.1. My self deceiving justification in t
122.
by hermanhermitage 14y ago
Long live mgl/sgl! The mention about hardware dedupe/filtering was more a hat tip to culling sub pixel triangles and early culling of obscured primitives that seems to happen on many chips these days :)
123.
by hermanhermitage 14y ago
Quite true. But there is another word there "only".
124.
by hermanhermitage 14y ago
Disclaimer: I've dabbled as a driver writer in a past life - but not OpenGL ES. The problem is a 100% compatibility layer is not necessarily easy nor valuable. The makers of OpenGL ES don't want a lifetime of maintaining someone elses prob
125.
by hermanhermitage 14y ago
OpenGL ES is not designed to be OpenGL. It has a different set of constraints. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple. For sure it would be nice if it came with a client si
126.
by hermanhermitage 14y ago
Indeed. It seems pretty clear to me it is framed as an benchmark of non tuned idiomatic performance. Maybe it doesn't call it out explicitly - but in my view that is a reasonable enough test. I'm pretty sure all the platforms could support
127.
by hermanhermitage 14y ago
It would be interesting to see someone go through a public repository and compare error rates / bug fixes between dynamic and static languages implementing the same kind of products. Might not point out differences in the approach but at l
128.
by hermanhermitage 14y ago
> I am going to make the bold claim that everyone should know C. I agree. The world of software is built on layers of abstractions. Both the skill of effortlessly layering abstractions and also the skill of peeling them away are fundam
129.
by hermanhermitage 14y ago
Thanks for sharing! this is an incredibly useful list for me. I'd already using some of the tools of the list, so very keen to try the others.
130.
by hermanhermitage 14y ago
These results mirror the experiences I've had with large JSON payloads of time series data and experimenting with different wire formats. The best message sizes I have obtained by custom compressors with complex predictive models and bit le
131.
by hermanhermitage 14y ago
Some syntax issues (no function pointers, no lambda, no rich literals, enforcing everything to reside in an object) endears it to Enterprise OO mindset where you want large teams of programmers working "efficiently" - but ultimately a risk
132.
by hermanhermitage 14y ago
Flights is a bit thin on, hotelfinder is better but on my iPad here it's got that typical clunky google UI feel - and to be fair they aren't a design or GUI strong company - but it's clear they are making steps to address it. Good point - A
133.
by hermanhermitage 14y ago
Having used GWT for a large web application it is hard to say much positive about building web client applications in Java. The GWT compiler technology and debugger support are great... but the flaws and rigidity of the Java language are so
134.
by hermanhermitage 14y ago
I'm kind of playing in the same space, although I tend to be more a hardware/assembler guy. Im currently prototyping with nodejs and C/C++ with inline assembler for AVX crunching. I would view Node.js as an effective tool for leveraging js
135.
by hermanhermitage 14y ago
I'm a joint Australian/UK citizen, I work in Stockholm from time to time (usually 3-6 months bursts). Because of my pattern the tax issue is a non issue for me. I would agree with all the positives posted here. The only notable negatives
136.
by hermanhermitage 14y ago
Yes a very interesting point. You could even replace C in that sentence with Algol and it rings fairly true. In C it always feels like the pillars were speed of implementation and speed of execution on low cost hardware and without sophist
137.
by hermanhermitage 14y ago
I'm not too fussed with the namespaces - I dont think you will find anyone arguing against that. What is at issue is the over specialization of class or framework components because of language limitations. A language that leads to degenera
138.
by hermanhermitage 14y ago
One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people rea
139.
by hermanhermitage 14y ago
I'm in two minds, I want a near native code execution environment in the browser but wonder if something like Xax offers better room for performance of dynamic generated code.
140.
by hermanhermitage 14y ago
Very easy to embed and small footprint. Language evolution has been implementation driven more so than say Javascript. As such its been able to reshape itself continually. Mike's LuaJit is an incredible piece of work. Its easily extended.
141.
by hermanhermitage 14y ago
I have problem with this line: The benefit therefor seems slim and highly niche. It's easy to say "situation X does not occur often". It's much more valuable to actually prove it with numbers that show how often it is used across the
142.
by hermanhermitage 14y ago
Makes perfect sense. I'm also thinking how the vm/language could self extend in the field. How the SIMD extensions (or any feature) could be introduced a-posteriori or independent from browser release cycle.
143.
by hermanhermitage 14y ago
I agree totally about removing the separation between assembly level coding and higher level coding. With current ISAs no matter how much genius is thrown at GC/JIT its always going to yield a layer of overhead. The pipes are a fixed with,
144.
by hermanhermitage 14y ago
Dave, is there any way to get involved? There would always be the option of running the code out into a raw VM host using NaCL or Xax style container (I know Mozilla dont see these approaches as necessarily compatible with the open web). B
145.
by hermanhermitage 14y ago
There is still a lot of performance slippage out there in high level languages (eg look at the need for assembly when people write raw codecs in C - x264 etc). We are rapidly approaching the battery wall on mobile devices and the clock wal
146.
by hermanhermitage 14y ago
I like to see this line of work. I'd really love to see a Frankenstein of: * C/Javascript/Lisp on an augmented LuaJit (structs, efficient array slices, machine word types). * dual syntax interchangable S-EXPR and C{}. * lang(machine) { inst
147.
by hermanhermitage 15y ago
vector<double> c(MM); => Initializes all c[i] to 0.0. Thus it writes to each entry (causing a cache fill or cache allocate depending on copy-back versus write-thru configuration of cache). Thus in the timed C++ loop access to
148.
by hermanhermitage 15y ago
The inner loop the author is benchmarking is doing different things between the versions. In the C++ version they are hot loading c[] into the cache outside of the timing loop with: vector<double> c[M]; In the C version you are doi