Earlier quoted context omitted.
Java build times are very fast. You are just measuring your internet speed here. (Also, gradle is faster as a build tool for incremental compilation)
Gradle is faster than what? Than maven? Maybe. But not than Go or Cargo.
The One Billion Row Challenge
51–60 of 366 posts
Re: The One Billion Row Challenge
#52but… can I use pandas?
Re: The One Billion Row Challenge
#53Re: The One Billion Row Challenge
#54> Each contender will be run five times in a row. The slowest and the fastest runs are discarded. The mean value of the remaining three runs is the result for that contender and will be added to the leaderboard. Shouldn’t he take the single fastest time, assuming file (and JDK) being in file cache is controlled for?
This is done to simulate real-world performance. Your binary is not the only binary in the system and other services may be running as well. So fastest time is the happiest path and slowest is the unluckiest. The range of remaining three is what you expect to get 99% of the time on a real world system.
Technically yes, but these days most of my machines are single purpose VMs; database/load balancer/app server/etc, so it still seems weird not to take the fastest.
Re: The One Billion Row Challenge
#55> write a Java program for retrieving temperature measurement values from a text file and calculating the min, mean, and max temperature per weather station
Depending on how far you want to stretch it, doesn’t precomputing the result on 1st run count too? Or pre-parsing the numbers into a compact format you can just slurp directly into rolling sums for subsequent runs.
Not the slightest in the spirit of the competition, but not against the rules as far as I can tell.
Edit: if we don't like pre-computation, we can still play with fancy out-of-the-box tricks like pre-sorting the input, pre-parsing, compacting, aligning everything, etc.
Edit 2: while we're here, why not just patch the calculate_time script to return 0 seconds :) And return 9999 for competitors, for good measure
Re: The One Billion Row Challenge
#56Earlier quoted context omitted.
This is done to simulate real-world performance. Your binary is not the only binary in the system and other services may be running as well. So fastest time is the happiest path and slowest is the unluckiest. The range of remaining three is what you expect to get 99% of the time on a real world system.
> Your binary is not the only binary in the system and other services may be running as well. Technically yes, but these days most of my machines are single purpose VMs; database/load balancer/app server/etc, so it still seems weird not to take the fastest.
As long as you share the metal with other stuff (be it containers, binaries, VMs), there's always competition for resources, and your average time becomes your real world time.
Re: The One Billion Row Challenge
#57Re: The One Billion Row Challenge
#58Earlier quoted context omitted.
1 billion is small for hadoop?
If it fits on one computer it's not a hadoop problem.
Re: The One Billion Row Challenge
#59The rule lawyer in me wants to spend the first run spinning up a background daemon that loads everything into memory, pins it there, and maybe even prefetches everything into cache as the subsequent runs perform basically a linear scan (you never have to pagemiss if you have an oracle!). > write a Java program for retrieving temperature measurement values from a text file and calculating the min, mean, and max temper…
> The computation must happen at application runtime, i.e. you cannot process the measurements file at build time (for instance, when using GraalVM) and just bake the result into the binary
Re: The One Billion Row Challenge
#60I don't understand, it should be pretty easy. A rolling average with BigDecimal would probably be sufficient but a scientific lib might be better for a rolling average or more than a hundred million numbers. https://stackoverflow.com/questions/277309/java-floating-poi...