Pall haraldsson patch 1 1 #3
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…liaLang#50374) * ensure GC_FINAL_STATS is consistent with new page metadata layout
* Set `VERSION` to `1.11.0-DEV` * move NEWS to HISTORY Co-authored-by: KristofferC <kristoffer.carlsson@juliacomputing.com>
* Extend ifelse lifting to regular SROA * Fix oracle violation This is a pre-existing bug, but was exposed by my improvements to SROA.
…Lang#50259) * fix(stdlib/Dates/periods.jl): conversion of empty CompoundPeriod to zero units * add(stdlib/Dates/test/periods.jl): add test for empty CompoundPeriod
Co-authored-by: Gabriel Baraldi <baraldigabriel@gmail.com>
The new commands are \guillemotleft and \guillemotright, respectively. These commands are in line with the corresponding commands defined in the LaTeΧ package csquotes. Co-authored-by: Steven G. Johnson <stevenj@mit.edu>
Our inlining cost model is extremely primitive, though surprisingly functional given its limitations. The basic idea for it was just that we'd give every intrinsic the approximate cost in cycles, such that for sufficiently large functions (>100 cycles), the cost of the extra call would be dwarfed by the cost of the function. However, there's a few problems with this. For one, the real issue is usually not the extra overhead of the call (which is small and well-predicated), but rather the inhibition of optimizations that inlining might have allowed. Additionally, the relevant cost comparison is not generally latency, but rather the size of the resulting binary. Lastly, the latency metric is misleading on modern superscalar architectures, because the core will perform other tasks while the operation is executing. In fact, somewhat counter-intuitively, this means that it is *more* important to inline high-latency instructions to allow the compiler to perform better latency hiding by spreading out the high-latency instructions. We probably need a full-on rethink of the inlining model at some point, but for the time being, this fixes a problem that I ran into in real code by reducing the inlining cost for floating point division to be the same as that of floating point multiplication. The particular case where I saw this was the batched forward AD rule for division, which had 6 calls to div_float. Inlining these provided substantially better performance.
Lower inlining cost of floating point div
…aLang#50421) Co-authored-by: Steven G. Johnson <stevenj@mit.edu>
Co-authored-by: Daniel Karrasch <daniel.karrasch@posteo.de>
* Add GC metric `last_incremental_sweep` * Update gc.c * Update gc.c
Note that this defines the lock order as `out` then `in` for streams which may try to take both locks. This is now a mandatory API convention for all future streams. Co-authored-by: Rafael Fourquet <fourquet.rafael@gmail.com>
…50430) Because `only` uses iteration, similar to the other branches here, rather than assuming it supports one-based-indexing.
…#50764) This makes irinterp not override `:nothrow=true` that are assumed by `Base.@assume_effects`.
``` o | Version 1.10.0-beta1 (2023-07-25) o o | Official https://julialang.org/ release ``` --------- Co-authored-by: Claire Foster <aka.c42f@gmail.com>
The descriptions had `i <= 5` while the code block had `i <=3`.
…ompact!`-ion (JuliaLang#50767) In code like below ```julia Base.@assume_effects :nothrow function erase_before_inlining(x, y) z = sin(y) if x return "julia" end return z end let y::Float64 length(erase_before_inlining(true, y)) end ``` the constant prop' can figure out the constant return type of `erase_before_inlining(true, y)` while it is profitable not to inline expand it since otherwise we left some `!:nothrow` callees there (xref: JuliaLang#47305). In order to workaround this problem, this commit makes `compact!`move inlineable constants into argument positions so that the such "inlineable, but safe as a whole" calls to be erased during compaction. This should give us general compile-time performance improvement too as we no longer need to expand the IR for those calls. Requires: - JuliaLang#50764 - JuliaLang#50765 - JuliaLang#50768
…wing `InexactError`. (JuliaLang#50777)
If something odd happens during GC (the PC goes to sleep) or a very big transient the heuristics might make a bad decision. What this PR implements is if we try to make our target more than double the one we had before we fallback to a more conservative method. This fixes the new issue @vtjnash found in JuliaLang#40644 for me.
fixes JuliaLang#50780 caused by JuliaLang#47013.
``` julia> @CCall jl_dump_host_cpu()::Cvoid CPU: znver2 Features: sse3, pclmul, ssse3, fma, cx16, sse4.1, sse4.2, movbe, popcnt, aes, xsave, avx, f16c, rdrnd, fsgsbase, bmi, avx2, bmi2, rdseed, adx, clflushopt, clwb, sha, rdpid, sahf, lzcnt, sse4a, prfchw, mwaitx, xsaveopt, xsavec, xsaves, clzero, wbnoinvd julia> target = only(Base.current_image_targets()) znver2; flags=0; features_en=(sse3, pclmul, ssse3, fma, cx16, sse4.1, sse4.2, movbe, popcnt, aes, xsave, avx, f16c, fsgsbase, bmi, avx2, bmi2, adx, clflushopt, clwb, sha, rdpid, sahf, lzcnt, sse4a, prfchw, mwaitx, xsavec, xsaves, clzero, wbnoinvd) ``` Co-authored-by: Prem Chintalapudi <prem.chintalapudi@gmail.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com>
…when partitioning (JuliaLang#50791)
Followup to JuliaLang#45964, JuliaLang#46506, and https://discourse.julialang.org/t/class-of-variables/83892. The error ``` julia> println(_) ERROR: syntax: all-underscore identifier used as rvalue ``` is hard to interpret if you are not familiar with the term `rvalue`, which is not used in any other context in Julia, and as discussed previously the use here is not clearly matching the wikipedia page referred to in the documentation either. This PR does away with the term `rvalue` by changing the error to ``` ERROR: syntax: all-underscore identifiers are write-only and their values cannot be used in expressions ``` and updates the documentation accordingly.
We don't really use anything meaningful from libm for this to matter much.
…uliaLang#50844) Detailed discussion and benchmarks by @oscardssmith in JuliaPackaging/Yggdrasil#7189
…#50851) Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
This bumps the build numbers for stdlib and binary dependency JLLs, updates libssh2 to 1.11.0, libgit2 to 1.6.4, and objconv to 2.53. Julia's FreeBSD CI has been running on FreeBSD 13.2 for a while, but until more recently, Yggdrasil was still building FreeBSD binaries using the 12.2 sysroot. The sysroot was updated to 13.2 and I went through and rebuilt the dependencies that Julia uses. The updated build numbers correspond to these rebuilt but otherwise unchanged binaries. The actual version updates are because libssh2 in Yggdrasil was at 1.11.0 so I left it there (its [release notes](https://github.com/libssh2/libssh2/releases/tag/libssh2-1.11.0) suggest it's a safe update), libgit2 had a newer patch version available and needed to be fixed anyway since the Windows build was broken, and objconv needed its Yggdrasil build recipe fixed but Elliot's GitHub mirror of objconv was at 2.53 so I updated to use that.
PallHaraldsson
pushed a commit
that referenced
this pull request
Dec 8, 2024
This PR introduces a new, toplevel-only, syntax form `:worldinc` that semantically represents the effect of raising the current task's world age to the latest world for the remainder of the current toplevel evaluation (that context being an entry to `eval` or a module expression). For detailed motivation on why this is desirable, see JuliaLang#55145, which I won't repeat here, but the gist is that we never really defined when world-age increments and worse are inconsistent about it. This is something we need to figure out now, because the bindings partition work will make world age even more observable via bindings. Having created a mechanism for world age increments, the big question is one of policy, i.e. when should these world age increments be inserted. Several reasonable options exist: 1. After world-age affecting syntax constructs (as proprosed in JuliaLang#55145) 2. Option 1 + some reasonable additional cases that people rely on 3. Before any top level `call` expression 4. Before any expression at toplevel whatsover As an example, case, consider `a == a` at toplevel. Depending on the semantics that could either be the same as in local scope, or each of the four world age dependent lookups (three binding lookups, one method lookup) could (potentially) occur in a different world age. The general tradeoff here is between the risk of exposing the user to confusing world age errors and our ability to optimize top-level code (in general, any `:worldinc` statement will require us to fully pessimize or recompile all following code). This PR basically implements option 2 with the following semantics: 1. The interpreter explicit raises the world age only at `:worldinc` exprs or after `:module` exprs. 2. The frontend inserts `:worldinc` after all struct definitions, method definitions, `using` and `import. 3. The `@eval` macro inserts a worldinc following the call to `eval` if at toplevel 4. A literal (syntactic) call to `include` gains an implicit `worldinc`. Of these the fourth is probably the most questionable, but is necessary to make this non-breaking for most code patterns. Perhaps it would have been better to make `include` a macro from the beginning (esp because it already has semantics that look a little like reaching into the calling module), but that ship has sailed. Unfortunately, I don't see any good intermediate options between this PR and option #3 above. I think option #3 is closest to what we have right now, but if we were to choose it and actually fix the soundness issues, I expect that we would be destroying all performance of global-scope code. For this reason, I would like to try to make the version in this PR work, even if the semantics are a little ugly. The biggest pattern that this PR does not catch is: ``` eval(:(f() = 1)) f() ``` We could apply the same `include` special case to eval, but given the existence of `@eval` which allows addressing this at the macro level, I decided not to. We can decide which way we want to go on this based on what the package ecosystem looks like.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.