|
If you've seen 1000x speed-ups from language implementation work, it mostly means the previous language implementation was some real embarrassing poo poo.
|
#
?
Jan 18, 2017 22:39
|
|
|
|
| # ? Jun 6, 2024 20:25 |
|
|
NihilCredo posted:Your post contains two apparently contradictory assumptions which, after thinking about it and adding the qualifiers in the spoilers, I realised actually combine to form a dreadful, dreadful lemma: And this is why PHP is still prevalent. It's me, i'm the the horror using PHP still. (I'm teaching myself new languages though!)
|
|
#
?
Jan 18, 2017 22:43
|
|
|
A most excellent observation, call it Nihil's Credo.
|
|
#
?
Jan 19, 2017 00:13
|
|
|
NihilCredo posted:Therefore, the worst programmers on the market will determine what languages the best programmers will be forced to learn and write in. Why do you think Java exists?
|
|
#
?
Jan 19, 2017 02:07
|
|
|
NihilCredo posted:Your post contains two apparently contradictory assumptions which, after thinking about it and adding the qualifiers in the spoilers, I realised actually combine to form a dreadful, dreadful lemma: 
|
|
#
?
Jan 19, 2017 02:25
|
|
|
Beef posted:How does the Erlang VM do for high-performance work? It's great for coordination and concurrency work, but how does it perform for keeping that 10-core xeon at a high IPC? Erlang will keep all your cores hot if there's tasks to back it, but it's not extremely good at crunching numbers. I've heard of people using it essentially as a scheduler for tasks to great effect. Using all your cores /is/ concurrency. Ease of multi core programming in erlang was Armstrong's siren song for years.
|
|
#
?
Jan 19, 2017 02:36
|
|
|
Nor does "high IPC" stand alone as a reasonable goal. How exactly do you think an article from 6 months earlier addresses the one you quoted? It hammers on "pause time" a heck of a lot but doesn't address overhead, compaction, or any of the other 12 tradeoffs the critical article brought up. 100% overhead would be unacceptable in my domain but I guess Twitch didn't care so it's irrelevant.
|
|
#
?
Jan 19, 2017 02:39
|
|
|
Sprinkle NOPs liberally and you can drive your IPC as high as you want. Erlang is pretty bad for high-performance computing. Most languages are. The best mainstream option is to use whatever language you want, and call into optimised matrix libraries.
|
|
#
?
Jan 19, 2017 10:35
|
|
|
JawnV6 posted:Nor does "high IPC" stand alone as a reasonable goal. No, I'm asking as a performance indicator for crunching said numbers. The plan9 article was responding to marketing bullshit. It ends on "But if you do wish to minimize pause times at the expense of everything else, then by all means, check out the Go GC.". Guess what Twitch cares about. On a tangent: Does anyone have any material on the rate of 'accidental' garbage produced by various language runtimes? A colleague claimed that his Java implementation was producing a higher volume of garbage than the equivalent Go implementation. (He's a former Java weenie, so at least I trust he knows what he is doing in Java.) edit: A quick glance at http://benchmarksgame.alioth.debian.org/u64q/go.html seems to support it, although it's not necessarily runtime garbage taking in the space. Beef fucked around with this message at 11:13 on Jan 19, 2017 |
|
#
?
Jan 19, 2017 10:38
|
|
|
Athas posted:The best mainstream option is to use whatever language you want, and call into optimised matrix libraries. it's a bit more complex than that. Unless you are dealing with huge matrices, your sequential 'driver' thread will be wrecking your parallel performance. I just profiled a Python Deep Learning library that spends 87% of its cycles spinning on 8 cores. (so yeah, very low IPC) A python script calling lots of smaller BLAS routines will be spending a lot of cycles spinning on OpenMP barriers. More ideally, you want your entire program control flow to be multithreaded, or Amdahl will come over to your house and do something horrible to your sequential parts. Libraries like TensorFlow use Python to wire together entire computational graphs, then handing everything over to C++. Python Dask does something similar for doing multithreading in python. I had high hopes for Julia 
|
|
#
?
Jan 19, 2017 10:56
|
|
|
On the subject of GC horrors: https://engineering.instagram.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172#.6hiyt3l65 10% efficiency gain by just disabling the CPython GC 
|
|
#
?
Jan 19, 2017 14:34
|
|
|
Beef posted:I had high hopes for Julia What's wrong with it?
|
|
#
?
Jan 19, 2017 15:06
|
|
|
Hm, I expected Erlang and Elixir's performance on multiple cores to be a lot more...well, performant. Just given that OTP favors a distributed, parallel method of computation and system design. Though that might ultimately be for purposes of uptime and stability rather than performance....Different needs, I guess. Turns out there's no easy solution, who knew v vleper khan posted:Erlang will keep all your cores hot if there's tasks to back it, but it's not extremely good at crunching numbers. I've heard of people using it essentially as a scheduler for tasks to great effect. Offloading hardcore tasks to languages like C seems to be pretty common in OTP, yes.
|
|
#
?
Jan 19, 2017 15:30
|
|
|
Bognar posted:Go is great as a honeypot for bad opinions. Some excellent examples in the comments of this article: https://research.swtch.com/go2017 quote:I have never understood generics. Why can't you just decide what data type to use beforehand? quote:I feel like most people *say* they want full-blown generics when really they just want map/filter/reduce. quote:One way out of the generics is to use reflection. However, it's not efficient to invoke the functions via reflection in tight loops. If there is a way to avoid the repeated work inside reflect.Value.Call(), it will be super nice already.
|
|
#
?
Jan 19, 2017 16:33
|
|
|
quote:I have never understood generics. Why can't you just decide what data type to use beforehand? Haha, so good.... Soooooo goooood
|
|
#
?
Jan 19, 2017 16:42
|
|
|
I have never understood functions. Why can't you just decide what values to use beforehand?
|
|
#
?
Jan 19, 2017 16:44
|
|
|
I have never understood programs. Why can't the clients just decide what output they want beforehand?
|
|
#
?
Jan 19, 2017 17:22
|
|
|
Just put it in the cloud, that solves everything.
|
|
#
?
Jan 19, 2017 17:27
|
|
|
Pollyanna posted:Hm, I expected Erlang and Elixir's performance on multiple cores to be a lot more...well, performant. Just given that OTP favors a distributed, parallel method of computation and system design. Though that might ultimately be for purposes of uptime and stability rather than performance....Different needs, I guess. Turns out there's no easy solution, who knew v There is a reason there is no even remotely mainstream parallel programming language (in fact, they are probably all research languages). Even concurrent languages are rare, although less so. poo poo's hard. Well, I guess maybe SQL can be considered parallel, or Prolog or something else with little sequential semantics.
|
|
#
?
Jan 19, 2017 17:42
|
|
|
Beef posted:No, I'm asking as a performance indicator for crunching said numbers. Twitch cares about both the latency and the throughput of its servers; it's just easier to scale throughput by throwing more hardware at it. For Twitch chat servers specifically, where the volume is not so high that doubling the hardware requirements is crippling, that may be an acceptable expense. There are certainly benefits to writing things in Go — it's a simple language for people to pick up, it provides strong guarantees about basic memory safety, and it provides some fairly elegant tools for concurrency (although it does have thread-safety holes). But understand what that post is really saying: they wrote their chat server in Python, then ported it to Go and found that their performance badly regressed. They just lived with it for years because it did at least improve throughput vs. Python and nobody really cares if there's a hiccup in the endless stream of emote spam. It's only the most recent versions of Go that have finally made things remotely acceptable. Beef posted:On a tangent: Does anyone have any material on the rate of 'accidental' garbage produced by various language runtimes? A colleague claimed that his Java implementation was producing a higher volume of garbage than the equivalent Go implementation. (He's a former Java weenie, so at least I trust he knows what he is doing in Java.) Different languages, and the idioms used in them, definitely produce somewhat different garbage profiles. Java in particular produces a lot because the language and VM have no ability to abstract directly over fundamental value types, so e.g. making a List of ints requires implicitly boxing of all the elements, etc. But my understanding is that the garbage profile isn't all that different in C#, which does have the ability to abstract over value types in the VM. Go isn't a VM language, it's directly compiled, so whether it has similar implementation limitations leading to lots of temporary garbage really depends on how interface{} is implemented under the covers; but I'm sure it still has the basic performance characteristic of rapidly blowing out the young generation due to some sort of temporary allocation.
|
|
#
?
Jan 19, 2017 18:23
|
|
|
Shader languages could probably be considered parallel. Also openCL and cuda, although they're just modified c/c++
|
|
#
?
Jan 19, 2017 18:25
|
|
|
Beef posted:The plan9 article was responding to marketing bullshit. It ends on "But if you do wish to minimize pause times at the expense of everything else, then by all means, check out the Go GC.". Guess what Twitch cares about. I don't have to guess, they mention it 34 times. And finding one customer very sensitive to one metric still doesn't seem to address the other 12. Again, is 100% overhead fine for everybody because Twitch didn't happen to be memory constrained 6 months ago? Or is the GC space perhaps larger than one company's old python script?
|
|
#
?
Jan 19, 2017 20:21
|
|
|
rjmccall posted:If you've seen 1000x speed-ups from language implementation work, it mostly means the previous language implementation was some real embarrassing poo poo. go: mating a 1970s language design with a 1990s implementation
|
|
#
?
Jan 19, 2017 20:31
|
|
|
code:
|
|
#
?
Jan 19, 2017 21:04
|
|
|
You reminded me of one. A guy who always put else at the end of every conditional block!code:
|
|
#
?
Jan 19, 2017 21:41
|
|
|
Beef posted:I had high hopes for Julia Athas posted:What's wrong with it? I can't speak for Beef, but in my view it's become kind of a niche language. This article summarizes some of the reasons (and mentions some other concerns that I think are just nitpicks). Its target audience is the scientific community, but most scientists don't really have the kind of knowledge that julia requires in order to use it effectively. It also just started gaining popularity right when the Python Numba module was also gaining popularity. Julia and Numba are not the same thing, but they serve a similar goal: provide a simple way for scientists to continue writing high level code while giving them the ability to compile the computationally-expensive segments. Given the choice between learning and getting set up with a new language vs learning how to use a new Python module, I know what most people would choose.
|
|
#
?
Jan 19, 2017 22:44
|
|
|
e:nm
|
|
#
?
Jan 19, 2017 22:58
|
|
|
Spatial posted:You reminded me of one. A guy who always put else at the end of every conditional block! Why??
|
|
#
?
Jan 19, 2017 23:09
|
|
|
HappyHippo posted:Why?? code:
|
|
#
?
Jan 19, 2017 23:13
|
|
|
HappyHippo posted:Why??
|
|
#
?
Jan 19, 2017 23:13
|
|
|
Spatial posted:You reminded me of one. A guy who always put else at the end of every conditional block! This guy is working up to omit that critical ; after the else right when everybody got used to it and stopped looking closely, to enable some rad backdoor.
|
|
#
?
Jan 19, 2017 23:41
|
|
|
rjmccall posted:But my understanding is that the garbage profile isn't all that different in C#, which does have the ability to abstract over value types in the VM. Yeah. I don't recall making any lists of unboxed integers in my C# job or really significantly taking advantage of value types elsewhere.
|
|
#
?
Jan 19, 2017 23:41
|
|
|
Vanadium posted:This guy is working up to omit that critical ; after the else right when everybody got used to it and stopped looking closely, to enable some rad backdoor. 
|
|
#
?
Jan 20, 2017 00:26
|
|
|
sarehu posted:Yeah. I don't recall making any lists of unboxed integers in my C# job or really significantly taking advantage of value types elsewhere. C#'s generics don't box value types. A List<int> won't generate nearly as much garbage as the Java equivalent.
|
|
#
?
Jan 20, 2017 00:57
|
|
|
QuarkJets posted:It also just started gaining popularity right when the Python Numba module was also gaining popularity. Julia and Numba are not the same thing, but they serve a similar goal: provide a simple way for scientists to continue writing high level code while giving them the ability to compile the computationally-expensive segments. Given the choice between learning and getting set up with a new language vs learning how to use a new Python module, I know what most people would choose. I think julia could have found a niche as a cython / numba alternative, and maybe could have used that to piggyback themselves into wider usage, but this would have required them to make calling julia from other languages really easy. When I looked into this a few years ago the devs were enthusiastically building tools to call other languages from julia, but had no interest at all in the other direction. There is basically no story for "I have a ton of code in python and would like to add in a bit of julia".
|
|
#
?
Jan 20, 2017 01:12
|
|
|
redleader posted:C#'s generics don't box value types. A List<int> won't generate nearly as much garbage as the Java equivalent. I know, and... we didn't make any List<int>'s. Or any List<struct>'s either.
|
|
#
?
Jan 20, 2017 01:55
|
|
|
Nippashish posted:I think julia could have found a niche as a cython / numba alternative, and maybe could have used that to piggyback themselves into wider usage, but this would have required them to make calling julia from other languages really easy. When I looked into this a few years ago the devs were enthusiastically building tools to call other languages from julia, but had no interest at all in the other direction. There is basically no story for "I have a ton of code in python and would like to add in a bit of julia". It also doesn't help that probably the widest-used Python package manager, Anaconda, comes with Numba. Continuum makes it really, really easy to just use their stuff. It's the MathWorks approach but without the "this becomes very hard later if you don't give us a million dollars" factor
|
|
#
?
Jan 20, 2017 09:14
|
|
|
redleader posted:C#'s generics don't box value types. A List<int> won't generate nearly as much garbage as the Java equivalent. except that anyone working with lists of integers in java who finds this to be a problem will be using one of the approximately gazillion libraries that provide memory-efficient primitive specializations of all the data structures, so it's not really a problem in practice. unless you have some code that needs to be completely generic and operate efficiently on lists of specific primitive types, but that's not very common.
|
|
#
?
Jan 20, 2017 10:42
|
|
|
Julia did not come with mutltithreading support, which is quite damning for a language that wants to be high performance (no C routines, everything in Julia philosophy). They are doing a lot of things right in the language design, but the rather limited multiprocessing and multithreading support means we had to look elsewhere. Over lunch, the creator assured me that the implementation was built from the ground up to include multithreading (delimited continuations?). The recent Julia release materialized a MT branch, but it's several years too late for our project. You will also notice the ungodly startup time due to the runtime compilation. They promised to at least have precompiled libraries, but I do not know what the current status of that is. In any case, Julia is one of the most interesting languages to keep an eye on if you're in scientific computing, but it's going to be a bitch to convince the army of R & Python programmers to switch over. Matlab programmers won't be hard to sway, just mention you it doesn't require a per-core license fee.
|
|
#
?
Jan 20, 2017 11:59
|
|
|
|
| # ? Jun 6, 2024 20:25 |
|
|
Beef posted:Matlab programmers won't be hard to sway, just mention you it doesn't require a per-core license fee. Scientists and engineers are insulated from the often-obscene costs of working with Matlab by a layer of managers who don't understand that that there are superior free alternatives for almost all of Matlab's use cases. Even if Julia was a 1:1 Matlab replacement that simply made everything run faster, you'd still be facing a ton of inertia from older engineers with Stockholm Syndrome
|
|
#
?
Jan 20, 2017 12:08
|
|