Live data from Hacker News

Viewing profile — bradcray

bradcray

HN member
Joined
Tue, May 24, 2016, 12:39 PM UTC
HN karma
39
Public activity
29 items

About bradcray

Brad is a Distinguished Technologist at Hewlett Packard Enterprise (formerly Cray Inc.) and the tech lead for the Chapel Parallel Programming Language project (https://chapel-lang.org).

Recent public activity

  1. comment
    Comment #47824865

    I disagree with the characterization that Chapel's parallelization features copied OpenMP without improving upon it: * Chapel's support for task parallelism predates OpenMP's (~200…

  2. comment
    Comment #47811290

    Good point on my alluding to demerits of Fortran, C, and C++ without stating them, and thanks for clarifying your criticism. Using the four factors that I focused on as attractive …

  3. comment
    Comment #47811118

    I'd say that the opposite is more often the reality, which is why HPC systems tend to have high-bandwidth, low-latency networks.

  4. comment
    Comment #47808417

    The evolution of C, C++, and Fortran is touched on in a sidebar, although admittedly very briefly: > Champions of Fortran, C++, MPI, or other entries on this list could argue that……

  5. comment
    Comment #47808400

    Author here: I didn't go into more detail on this than https://chapel-lang.org/blog/posts/30years/#maybe-hpc-doesnt... because I felt like the article was long enough already and t…

  6. comment
    Comment #44045461

    @yubblegum: I'm afraid we don't have an update on support for Apple GPUs since last year's comment. While it comes up from time-to-time, nobody has opened an issue for it yet (plea…

  7. comment
    Comment #44036069

    @yubblegum: I'm unfairly biased towards Chapel (positively), so won't try to characterize HN's opinion on it. But I did want to note that while Chapel's original and main reason fo…

  8. comment
    Comment #42952357

    The ~10-minute video for this talk is here, if anyone's interested in the narrative behind the slides: https://www.youtube.com/watch?v=U8KM8wv32js

  9. comment
    Comment #39032997

    We agree that the placement of data is important for HPC programmers to control. Locales are the means of controlling such placement in Chapel, whether directly (as in this article…

  10. comment
    Comment #39032481

    That doesn't seem extreme to me, as I generally feel similarly. If you (or other readers) are genuinely interested in using Chapel with Metal, please open an issue on our GitHub re…

  11. comment
    Comment #39021165

    These are great questions, and ones we’re very curious about as well. I don’t believe that our current Chapel team has much experience programming NNs and LLMs, having focused on o…

  12. comment
    Comment #39020976

    Chapel was designed for the high performance computing community where programmers often want full control over mapping their computations to their hardware resources without needi…

  13. comment
    Comment #38981366

    Sorry for what now appears to be a double-post. Engin had just registered for HN, hadn't seen his reply going through, so asked me to relay it. Re-reading this Q+A this morning, I …

  14. comment
    Comment #38970918

    @ColonelPhantom: Thanks very much for your questions. The following are answers I'm relaying from Engin Kayraklioglu, who heads up the Chapel GPU effort: Re Intel support: That's d…

  15. comment
    Comment #38349769

    I would say Chapel was created less to replace MPI and more to provide a higher-level alternative to it that is amenable to compiler optimization.

  16. comment
    Comment #37943705

    Those interested in the intersection between Python, HPC, and data science may want to take a look at Arkouda, which is a Python package for data science at massive scales (TB of m…

  17. comment
  18. comment
    Comment #37825801

    My answer would be that Chapel supports a partitioned global namespace such that a variable within the lexical scope of a given statement can be referenced whether it is local to t…

  19. comment
    Comment #37057561

    @cbkeller: Though MPI is dominant in HPC by a very large margin, it's definitely not the only game in town. SHMEM is an MPI alternative with a smaller but very dedicated following.…

  20. comment
    Comment #36993251

    My understanding is that the Julia Petaflops run executed a Julia program per node, communicating via MPI. For some, that's probably obvious/expected for HPC; for others, it might …

  21. comment
    Comment #36159773

    Thanks for the mention, @distortedsignal! Note that CHIUW 2023 is online and free, requiring just a quick Zoom registration from the URL above. Tomorrow's topics are more about rep…

  22. comment
    Comment #30267268

    @blueslurpee: I'm definitely biased, but agree that Chapel would be a fun language to explore, particularly if you're interested in looking at integrated task- and data-parallelism…

  23. comment
    Comment #29982721

    > Chapel, HPC language mostly sponsored by Intel and HPC Minor correction: Intel hasn't traditionally been a sponsor of Chapel (though we'd love to see that change). Chapel was pio…

  24. comment
    Comment #22743937

    @mardifoufs: I realize that your point is that the Chapel webpage didn't answer this question clearly / concisely for you and agree that we could and should improve that. The obser…

  25. comment
    Comment #22712489

    I think it's plausible you would want to use Chapel for every program you write. I definitely want to use it for every program I write, but I'm also biased. The main disincentive t…